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1. Introduction 


This document presents the base specifications for the Intelligent Platform Management Interface (IPMI) 
architecture. The IPMI specifications define standardized, abstracted interfaces to the platform management 
subsystem. IPMI includes the definition of interfaces for extending platform management between board within the 
main chassis, and between multiple chassis. 


The term “platform management” is used to refer to the monitoring and control functions that are built in to the 
platform hardware and primarily used for the purpose of monitoring the health of the system hardware. This 
typically includes monitoring elements such as system temperatures, voltages, fans, power supplies, bus errors, 
system physical security, etc. It includes automatic and manually driven recovery capabilities such as local or 
remote system resets and power on/off operations. It includes the Jogging of abnormal or ‘out-of-range’ conditions 
for later examination and alerting where the platform issues the alert without aid of run-time software. Lastly it 
includes inventory information that can help identify a failed hardware unit. 


This document is the main specification for IPMI. It defines the overall architecture, common commands, event 
formats, data records, and capabilities used across IPMI-based systems and peripheral chassis. This includes the 
specifications for IPMI management via LAN, serial/modem, PCI Management bus, and the local interface to the 
platform management. In addition to this document, there is a set of separate supporting specifications: 


e The Intelligent Platform Management Bus (IPMB) is an I?C*-based bus that provides a standardized 
interconnection between different boards within a chassis. The IPMB can also serve as a standardized interface 
for auxiliary or ‘emergency’ management add-in cards. 


e IPMB v1.0 Address Allocation documents the different ranges and assignments of addresses on the IPMB. 


e The Intelligent Chassis Management Bus (ICMB) provides a standardized interface for platform management 
information and control between chassis. The ICMB is designed so it can be implemented with a device that 
connects to the IPMB. This allows the ICMB to be implemented as an add-on to systems that have an existing 
IPMB. See [ICMB] for more information. 


e The Platform Event Trap Format specification defines the format of SNMP traps used for alerts. 


e The Platform Management FRU Information Storage Definition defines the format of Field Replaceable Unit 
information (information such as serial numbers and part numbers for various replaceable boards and other 
components) accessible in an IPMI-based system. 


The implementation of certain aspects of IPMI may require access to other specifications and documents that are not 
part Refer to the Reference Documents section below, for these and other supporting documents. 


1.1 Audience 


This document is written for engineers and system integrators involved in the design of and interface to platform 
management hardware, and System Management Software (SMS) developers. Familiarity with microcontrollers, 
software programming, and PC and Intel server architecture is assumed. For basic and/or supplemental 
information, refer to the appropriate reference documents. 


1.2 Reference Documents 
The following documents are companion and supporting specifications for IPMI and associated interfaces: 
[ACPI 1.0] Advanced Configuration and Power Interface Specification, Revision 1.0b, February 8, 1999. 


©1999, Copyright © 1996, 1997, 1998, 1999 Intel Corporation, Microsoft Corporation, Toshiba 
Corp. http://www.teleport.com/~acpi/ 


[ACPI 2.0] 


[AES] 


[ADDR] 


[ASF] 


[ASF 2.0] 


[BR1] 


[CBCP] 


[FIPS-180-2] 


[FRU] 


[PC] 


[ICMB] 


[IPMB] 


[MODES] 


[MSFT EMS] 


[MSVT] 
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Advanced Configuration and Power Interface Specification, Revision 2.0c, August 25, 2003. ©1996, 
1997, 1998, 1999, 2000, 2001, 2002, 2003 Compaq Computer Corporation, Intel Corporation, 
Microsoft Corporation, Phoenix Technologies Ltd., Toshiba Corporation. http://www.acpi.info 


Advanced Encryption Standard, FIPS 197, November 2001. 
http://csrc.nist.gov/publications/fips/fips 197/fips-197.pdf 


IPMB v1.0 Address Allocation, ©2001 Intel Corporation, Hewlett-Packard Company, NEC 
Corporation, and Dell Computer Corporation. This document specifies the allocation of PC 
addresses on the IPMB. http://developer.intel.com/design/servers/ipmi 


Alert Standard Format v1.0 Specification, ©2001, Distributed Management Task Force. 
http://www.dmtf.org 


Alert Standard Format (ASF) Specification Version 2.0, 23 April 2003, ©2000-2003, Distributed 
Management Task Force, Inc. http://www.dmtf.org 


Entity Authentication and Key Distribution, Bellare and Rogaway, 1993. 


Proposal for Callback Control Protocol (CBCP), draft-ietf-pppext-callback-cp-02.txt, N. Gidwani, 
Microsoft, July 19, 1994. As of this writing, the specification is available via the Microsoft 
Corporation web site: http://www.microsoft.com 


NIST, FIPS PUB 180-2: Secure Hash Standard, August 2002. 
http://csrc.nist.gov/publications/fips/fips 1 80-2/fips 180-2.pdf 


Platform Management FRU Information Storage Definition v1.0, ©1999 Intel Corporation, Hewlett- 
Packard Company, NEC Corporation, and Dell Computer Corporation. Provides the field definitions 
and format of Field Replaceable Unit (FRU) information. 
http://developer.intel.com/design/servers/ipmi 


The FC Bus And How To Use It, ©1995, Philips Semiconductors. This document provides the 
timing and electrical specifications for DC busses. 


Intelligent Chassis Management Bus Bridge Specification v1.0, rev. 1.3, © 2002 Intel Corporation. 
Provides the electrical, transport protocol, and specific command specifications for the ICMB and 
information on the creation of management controllers that connect to the ICMB. 
http://developer.intel.com/design/servers/ipmi 


Intelligent Platform Management Bus Communications Protocol Specification v1.0, ©1998 Intel 
Corporation, Hewlett-Packard Company, NEC Corporation, and Dell Computer Corporation. This 
document provides the electrical, transport protocol, and specific command specifications for the 
Intelligent Platform Management Bus. 


Recommendation for Block Cipher Modes of Operation: Methods and Techniques, NIST Special 
Publication 800-38A, December 2001. 
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf 


Building Hardware and Firmware to Complement Microsoft Windows Headless Operation, Version 
1.00, July 16, 2002. http://www.microsoft.com/whdc/hwdev/platform/server/headless/ 
IPMB. http://developer.intel.com/design/servers/ipmi 


Windows Platform Design Notes, Building Hardware and Firmware to Complement Microsoft 
Windows Headless Operation, ©2001, Microsoft Corporation. http://www.microsoft.com 
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[PET] 


[RFC826] 


[RFC1319] 


[RFC 1321] 


[RFC 1332] 


[RFC 1334] 


[RFC 1661] 


[RFC 1662] 


[RFC 1994] 


[RFC2104] 


[RFC2153] 


[RFC2404] 


[RFC2433] 


[RFC2460] 


[RFC2464] 


[RFC2759] 


[RFC3315] 


[RFC4122] 


[RFC429 1] 


[RFC4294] 


IPMI Platform Event Trap Format Specification v1.0, ©1998, Intel Corporation, Hewlett-Packard 
Company, NEC Corporation, and Dell Computer Corporation. This document specifies a common 
format for SNMP Traps for platform events. 


An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48-bit 
Ethernet Address for Transmission on Ethernet Hardware, David C. Plummer, November 1982 


RFC 1319, The MD2 Message-Digest Algorithm, B. Kaliski, RSA Laboratories, April 1992. 


RFC 1321, The MDS Message-Digest Algorithm, R. Rivest, MIT Laboratory for Computer Science 
and RSA Data Security, Inc. April, 1992. 


RFC 1332, The PPP Internet Protocol Control Protocol (IPCP), G. McGreggor, Merit, May 1992. 


RFC 1334, PPP Authentication Protocols, B. Lloyd, L&A, W. Simpson, Daydreamer, October 
1992. Document includes specification for PAP (Password Authentication Protocol). 


RFC 1661, STD 51, The Point-to-Point Protocol (PPP), Simpson, W., Editor, Daydreamer, July 
1994. 


RFC 1662, STD 51, PPP in HDLC-like Framing, Simpson, W., Editor, Daydreamer, July 1994. 


RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), Simpson, W., Editor, 
Daydreamer August 1994. 


RFC 2104, HMAC: Keyed-Hashing for Message Authentication, H. Krawczyk, IBM, M. Bellare, 
UCSD, R. Canetti, IBM, February 1997. 
http://www. ietf.org/rfc/rfc2 104.txt 


RFC 2153, PPP Vendor Extensions, Simpson, W., Daydreamer, May 1997. 


RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH, C. Madson, Cisco Systems Inc., R. 
Glenn, NIST, November 1998. 
http://www. ietf.org/rfc/ric2404.txt 


RFC 2433, Microsoft PPP CHAP Extensions, G. Zorn / S. Cobb, Microsoft Corporation, October 
1998 


RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, S. Deering, Cisco; R. Hinden, Nokia; 
December 1998 


IPv6 Packets over Ethernet, M. Crawford, Fermilab; December 1998 
RFC 2759, Microsoft PPP CHAP Extensions, Version 2, G. Zorn, Microsoft Corporation, January 


2000 


Dynamic Host Configuration Protocol for IPv6 (DHCPv6), R. Droms, Ed.,Cisco; J. Bound, 
Hewlett Packard; B. Volz, Ericsson; T. Lemon, Nominum; C Perkins, Nokia Research Center; M. 
Carney; Sun Microsystems; July 2003 


RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace, P Leach, Microsoft; M. 
Mealling, Refactored Networks, LL; and R. Salz, DataPower Technology, Inc.; July 2005 


IPv6 Addressing Architecture, R. Hinden, Nokia; S. Deering, Cisco Systems; February 2006 


IPv6 Node Requirements, J. Loughney, Ed., Nokia; April 2006 


[RFC4634] 


[RFC4861] 


[RFC4862] 


[RFC4868] 


[SHA-1] 


[SMBIOS] 


[SMBUS] 


[TAP] 


[TIA-602] 
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US Secure Hash Algorithms (SHA and HMAC-SHA), D. Eastlake 3rd, Motorola Labs , T. Hansen, 
AT&T Labs, July 2006 


Neighbor Discovery for IPv6, T. Narten, IBM; E. Nordmark, Sun Microsystems; W. Simpson, 
Daydreamer; December 1998 


IPv6 Stateless Address Autoconfiguration, S. Thomson, Cisco; T. Narten, IBM; T. Jinmei, Toshiba; 
September 2007 


Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec, S. Kelly, Aruba 
Networks, S. Frankel, NIST, May 2007 


NIST, FIPS PUB 180-2: Secure Hash Standard, August 2002. 
http://csrc.nist.gov/publications/fips/fips 180-2/fips 180-2.pdf 


System Management BIOS (SMBIOS) Reference Specification, Version 2.4, July 21, 2004. 
Copyright © "2000, 2002, 2004" Distributed Management Task Force, Inc. (DMTF). All rights 
reserved. 


System Management Bus (SMBus) Specification, Version 2.0, ©2000, Duracell Inc., Fujitsu Personal 
Systems Inc., Intel Corporation, Linear Technology Corporation, Maxim Integrated Products, 
Mitsubishi Electric Corporation, Moltech Power Systems, PowerSmart Inc., Toshiba Battery Co., 
Ltd., Unitrode Corporation, USAR Systems. 


Telocator Access Protocol version 1.8, February 04, 1997. ©1997, Personal Communications 
Industry Association. http://www.pcia.com (As of this writing, the document is found under 
“Wireless Resource Center | Protocols’, or: http://www.pcia.com/wireres/protocol.htm.) This 
document specifies a protocol for sending an alphanumeric page by connecting to a paging service 
via a serial modem. 


TIA/EIA Standard: Data Transmission Systems and Equipment - Serial Asynchronous Automatic 
Dialing and Control, TIA/EIA 602, June 1992. © 1992, Telecommunications Industry Association. 
Also available from the Electronic Industries Association. This document specifies the dialing 
protocol commonly used in asynchronous serial modems. 
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1.3 Conventions and Terminology 


If not explicitly indicated, bits in figures are numbered with the most significant bit on the left and the least 
significant bit on the right. 


This document uses the following terms and abbreviations: 


Table 1-, Glossary 
Term 


Asserted Active-high (positive true) signals are asserted when in the high electrical state (near power 
potential). Active-low (negative true) signals are asserted when in the low electrical state 
(near ground potential). 


BMC Baseboard Management Controller 


Bridge The circuitry that connects one computer bus to another, allowing an agent on one to access 
the other. 


Byte 
CMOS In terms of this specification, this describes the PC-AT compatible region of battery-backed 
128 bytes of memory, which normally resides on the baseboard. 

Deasserted | A signal is deasserted when in the inactive state. Active-low signal names have “_L” 
appended to the end of the signal mnemonic. Active-high signal names have no “_L” suffix. 

To reduce confusion when referring to active-high and active-low signals, the terms one/zero, 
high/low, and true/false are not used when describing signal states. 

Diagnostic A non-maskable interrupt or signal for generating diagnostic traces and ‘core dumps’ from the 
Interrupt operating system. Typically NMI on IA-32 systems, and an INIT on Itanium ™-based systems. 


Dword Double word is a 32-bit (4 byte) quantity. 


EEPROM Electrically Erasable Programmable Read Only Memory. 
EvM Notation for ‘Event Message’. See text for definitions of ‘Event Message’. 
FPC Front Panel Controller. 


FRB Fault Resilient Booting. A term used to describe system features and algorithms that improve 
the likelinood of the detection of, and recovery from, processor failures in a multiprocessor 
system. 

FRU Field Replaceable Unit. A module or component which will typically be replaced in its entirety 
as part of a field service repair operation. 

Hard Reset | A hardware reset event that initializes components and invalidates caches for a system or 

subsystem. In the context of this specification, the term Hard Reset is generally used to refer 

to System Hard Resets, where System Hard Resets are Hard Resets of the computer system 
that do not reset the BMC, Satellite Controllers, or other elements of the platform 
management subsystem. Unless explicitly stated, Hard Resets or System Hard Resets do not 
refer to resets of the BMC or other elements of the platform management subsystem. 

Inter-Integrated Circuit bus. A multi-master, 2-wire, serial bus used as the basis for the 

Intelligent Platform Management Bus. 

Intelligent Chassis Management Bus. A serial, differential bus designed for IPMI messaging 

between host and peripheral chassis. Refer to [ICMB] for more information. 

Internal Error. A signal from the Intel Architecture processors indicating an internal error 

condition. 

Intelligent Platform Management. 

Intelligent Platform Management Bus. Name for the architecture, protocol, and 

implementation of a special bus that interconnects the baseboard and chassis electronics 

and provides a communications media for system platform management information. The bus 
is built on IC and provides a communications path between ‘management controllers’ such 
as the BMC, FPC, HSC, PBC, and PSC. 

Industry Standard Architecture. Name for the basic ‘PC-AT’ functionality of an Intel 

Architecture computer system. 

1024 bytes 

Logical Unit Number. In the context of the Intelligent Platform Management Bus protocol, this 

is a sub-address that allows messages to be routed to different ‘logical units’ that reside 

behind the same I?C slave address. 
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Non-maskable Interrupt. The highest priority interrupt in the system, after SMI. This interrupt 
has traditionally been used to notify the operating system fatal system hardware error 
conditions, such as parity errors and unrecoverable bus errors. It is also used as a Diagnostic 
Interrupt for generating diagnostic traces and ‘core dumps’ from the operating system. 

RSA Data Security, Inc. MD2 Message-Digest Algorithm. An algorithm for forming a 128-bit 
digital signature for a set of input data. 

RSA Data Security, Inc. MD5 Message-Digest Algorithm. An algorithm for forming a 128-bit 
digital signature for a set of input data. Improved over earlier algorithms such as MD2. 

For this specification, the term ‘payload’ refers to the information bearing fields of a message. 
This is separate from those fields and elements that are used to transport the message from 
one point to another, such as address fields, framing bits, checksums, etc. In some 
instances, a given field may be both a payload field and a transport field. 

Platform Event Filtering. The name of the collection of IPMI interfaces in the IPMI v1.5 
specification that define how an IPMI Event can be compared against ‘filter table’ entries that, 
when matched, trigger a selectable action such as a system reset, power off, alert, etc. 


Parity Error. A signal on the PCI bus that indicates a parity error on the bus. 

Platform Event Trap. A specific format of SNMP Trap used for system management alerting. 
Used for IPMI Alerting as well as alerts using the ASF specification. The trap format is 
defined in the PET specification. See [PET] and [ASF] for more information. 


POST Power On Self Test. 


Re-arm Re-arm, in the context of this document, refers to resetting internal device state that tracks 
that an event has occurred such that the device will re-check the event condition and re- 
generate the event if the event condition exists. 

Sensor Data Record. A data record that provides platform management sensor type, 
locations, event generation, and access information. 


PEF 
PET 


SDR i 
d 
platform event information for later retrieval 

SERR System Error. A signal on the PCI bus that indicates a ‘fatal’ error on the bus. 

SMI 

SMIC Server Management Interface Chip. Name for one type of system interface to an IPMI 

Baseboard Management Controller. 

SMM System Management Mode. A special mode of Intel IA-32 processors, entered via an SMI. 

SMI is the highest priority non-maskable interrupt. The handler code for this interrupt is 


typically located in a physical memory space that is only accessible while in SMM. This 
memory region is typically loaded with SMI Handler code by the BIOS during POST. 


SMS System Management Software. Designed to run under the OS 


Soft Reset A reset event in the system which forces CPUs to execute from the boot address, but does 
not change the state of any caches or peripheral devices. 


Word A 16-bit quantity. 


S 


Background - Architectural Goals 


A number of goals/principles influence the design and implementation of a platform management subsystem that 
works across multiple platforms. The abstracted, modular, extensible interfaces specified in this document seek to 
satisfy those goals. The following review is provided to give a framework to assist in the evaluation options in the 
implementation of this specification. 


Provide Layered Management Value 


— Provide management value at each level of integration, and have the net value increase as each level is 
added. I.e. progressing from processor, through chip set, BIOS, baseboard, baseboard with 
management circuitry, with onboard networking, with intelligent controllers, with managed chassis, 
system management software, with Remote Management Cards, etc. 


— Maintain modularity so that one level does not carry undue cost burden for another. Levels should 
retain value if separated. Avoid burdening baseboard with cost for chassis-specific management 
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functions. Avoid building in functions that unduly impede OEMs in providing their own chassis 
management features. 


— Drive intelligence to appropriate level. Don’t put complexity in at a level if the next higher level can 
handle it. I.e. don’t do something with a microcontroller if the system’s host processor can do it more 
flexibly and economically. 


Plan for Evolution and Re-use 
— Architect so existing implementations can be cleanly extended with new functionality, without 
requiring existing functionality to be re-implemented or redesigned. 


— Architect for product families. Avoid ‘local optimizations’ that benefit one product at the cost of future 
projects. 


— Knowledge and understanding of the architecture is also a valuable commodity. “Re-inventing the 
wheel” often means retraining the wheel user. Design to preserve the knowledge base of developers, 
testers, salespersons, and customers by maintaining consistency in architecture and implementation - in 
hardware implementation, firmware, software, protocols, and interfaces. 


— Design for the economic incorporation of changes in the population and implementation of baseboard 
and remote sensors. Architect to minimize the impact to hardware and software when sensor 
population or sensor hardware interfaces change. 


— Design to maximize ‘self configurability’ in system management software. I.e. ‘Plug ‘N Play’. Provide 
platform resident discovery mechanisms, such as standardized tables, discovery mechanisms, etc. to 
reduce or eliminate the need to ‘customize’ system software for different platforms. 


Provide Scalability 
— Architecture should scale from entry through enterprise and data center class server systems. 
Architecture should be adaptable from single board and single chassis, through multi-board and multi- 
chassis systems. 


— Apply ‘Layered Management Value’ concept. Low-end solutions should be a proper functional subset 
of higher end solutions. Entry solutions should not carry undue burden for higher class systems. 


Support OEM Extensibility: 
— Provide clean points for OEM extension and integration. 


— Provide OEM support in protocol and command specifications. Reserve command numbers, sensor 
numbers, etc. for OEM extension. 


1.5 New for IPMI v1.5 


IPMI v1.5 is an extension of the v1.0 specification. IPMI v1.5 also includes learnings, feedback, and features 
gathered from industry review and experiences deploying IPMI v1.0 enabled systems. 


The following goals guided the creation of the IPMI v1.5 specification: 


e Help enable “Always Available Manageability” by enabling new access media: LAN, Serial/Modem, and 
PCI Management Bus. 


e Extend “Autonomous Manageability” by defining new automatic alerting and recovery mechanisms. 


e  Synch-up with and support emergent and existing standards such as PPP, the DMTF Pre-OS Working 
Group ‘Alert Standard Forum’ specification, SMBus 2.0, Compact PCI / AdvancedTCA, and the PCI 
Management Bus. 


e Retain as much backward compatibility with IPMI v1.0 as feasible 
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The following presents a brief summary of some of the more significant additions and enhancements in the IPMI 
v1.5 specification: 


Serial/Modem Messaging and Alerting 


The IPMI v1.5 specification defines how IPMI messaging can be accomplished via a direct serial or 
external modem connection to the BMC (Baseboard Management Controller). It also includes the 
specifications for generating alerts, numeric pages, and alphanumeric pages on events. 


Serial Port Sharing 


This is a capability that works in conjunction with serial/modem messaging and alerting and allows the 
baseboard serial connector to be shared between use by the BMC and use by the system. This enables 
coordination between system features such as console redirection and allows the serial connection to 
be used for run-time applications while still allowing it to be remotely accessed for ‘emergency’ 
management. 


Boot Options 


IPMI v1.5 includes a boot options ‘mailbox’ that can be used to direct the operation of BIOS and the 
booting process following a system power up or reset operation. 


LAN Messaging and Alerting 


The specification defines how IPMI messaging can be accomplished via a LAN connection to the 
BMC. It also includes the specifications for generating PET format SNMP traps on events. 


Extended BMC Messaging ‘Channel Model’ 


IPMI v1.0 introduced a limited capability to use a ‘Channel Number’ capability that was primarily 
used for routing messages to the IPMB. IPMI v1.5 expands on the use of channel numbers as a general 
mechanism for routing messages between different media and organizing the access 


Additional Sensor and Event Types 


Several new sensor types have been added to IPMI v1.5, including a Slot/Connector sensor for 
monitoring hot-plug slot status, an ACPI System Power State sensor to support out-of-band monitoring 
of the system power state, and an enhanced Watchdog sensor that supports events generated by the 
standardized watchdog timer function. 


Platform Event Filtering (PEF) 


Platform Event Filtering (PEF) provides a mechanism for configuring the BMC to taking selected 
actions on event messages that it receives or has internally generated. These actions include operations 
such as system power-off, system reset, as well as triggering the generation of an alert. 


Alert Policies 


Alert policies provide a configurable mechanism for configuring and controlling the delivery of an 
alert to multiple destinations. This enables the creation of ‘call down lists’ where one alert destination 
is tried first and then another. 
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1.6 New for IPMI v2.0 


IPMI v1.5 is an extension of the v1.5 specification. IPMI v2.0 adds new capabilities and incorporates learnings, 
feedback, and features gathered from industry review and experiences deploying IPMI v1.5 enabled systems. The 
following summarizes the most significant new features for IPMI v2.0: 


Enhanced Authentication 


Extensions to the protocols for IPMI over IP, collectively referred to as “RMCP+”, support new 
algorithms that provide more robust key exchange process for establishing sessions and authenticating 
users. These steps more closely align with those used for the DMTF ASF 2.0 specification (see 
[ASF2.0]), making it simpler to create applications that can connect to both ASF and IPMI-based 
system. 


VLAN Support 


Configuration options have been added to support IEEE 802.1q VLAN (virtual LAN) headers for IPMI 
over IP sessions on IEEE 802.3 Ethernet. VLAN works with VLAN-aware routers and switches to 
allow a physical network to be partitioned into ‘virtual’ networks where a group of devices on different 
physical LAN segments which can communicate with each other as if they were all on the same 
physical LAN segment. This can be used to isolate classes of network membership at the Ethernet 
Packet level rather than at the IP level, as might be done with a router. This can be used to set up a 
‘management VLAN’ where only devices that are members of that VLAN will receive packets related 
to management, and, conversely, will be isolated from the need to process network traffic for other 
VLANs. 


Serial Over LAN (SOL) 


Serial Over LAN provides a mechanism that enables the serial controller of a managed system to be 
redirected over an IPMI session over IP. This enables remote console applications to provide access to 
text-based interfaces for BIOS, utilities, operating systems, and applications while simultaneously 
providing access to IPMI platform management functions. SOL is implemented as a payload type 
under the new payload capability in RMCP+. 


Payloads 


RMCP+ adds the ability to enable IPMI over IP sessions to other types of traffic in addition to IPMI 
messages. This includes both standard payload types defined in the IPMI specification (such as SOL), 
and OEM ‘value-added’ payload types. 


Encryption Support 


IPMI messages and other payloads carried over RMCP+ can be encrypted. This enables confidential 
remote configuration of parameters such as user passwords and transfer of sensitive payload data over 
SOL. 


Extended User Login Options 


New options support “Role Only” logins for simple environments where it is desirable to just enable 
logins according to a given privilege level, without the need to assign or configure usernames. Support 
for “two-key” logins enables a BMC to be configured for a very robust environment, where both a 
user-specific and BMC-specific key are required to connect to a given BMC. 


Firmware Firewall 


Firmware Firewall is the name for a collection of commands that enable a BMC implementation to 
restrict the ability to execute certain commands or functions from a given interface. This can be used to 
protect against operations that errant or malicious software may use to affect the managed system or 
other systems. For example, this enables a BMC to block the ability for local software to send a 
Chassis Control command to reset another blade in a modular server implementation where BMCs on 
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individual blades share a common management bus across the blade backplane. Firmware Firewall 
includes a set of commands that enable software to discover which commands and functions are 
present and enabled on a given management controller. These commands can be used by themselves to 
provide a more efficient way for software and conformance tests to discover which features are 
available. 


SMBus System Interface (SSIF) 


The SMBus System Interface (SSIF) is a new, low pin-count, option for the hardware interface that 
provides local access to the BMC via a connection to the system’s SMBus host controller. SSIF helps 
support lower-cost BMC implementations by enabling an interface that can be used on low-cost 
microcontrollers in low pin-count packages. 
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1.7 IPMI Overview 


This section presents an overview of IPMI and its main elements and characteristics. 


1.7.1. Intelligent Platform Management 


The term Intelligent Platform Management refers to autonomous monitoring and recovery features implemented 
directly in platform management hardware and firmware. The key characteristic of Intelligent Platform 
Management is that inventory, monitoring, logging, and recovery control functions are available independent of 
the main processors, BIOS, and operating system. Platform management functions can also be made available 
when the system is in a powered down state. 


Intelligent Platform Management capabilities are a key component in providing enterprise-class management 
for high-availability systems. Platform status information can be obtained and recovery actions initiated under 
situations where system management software and normal ‘in-band’ management mechanisms are unavailable. 


The independent monitoring, logging, and access functions available through IPMI provide a level of 
manageability built-in to the platform hardware. This can support systems where there is no system 
management software available for the particular operating system, or the end-user elects not to load or enable 
the system management software. 


1.7.2 IPMI Relationship to other Management Standards 


IPMI is best used in conjunction with system management software running under the operating system. This 
provides an enhanced level of manageability by providing in-band access to the IPMI management information 
and integrating IPMI with the additional management functions provided by management applications and the 
OS. System management software and the OS can provide a more sophisticated control, error handling and 
alerting, than can be directly provided by the platform management subsystem. 


IPMI is a hardware level interface specification that is ‘management software neutral’ providing monitoring and 
control functions that can be exposed through standard management software interfaces such as DMI, WMI, 
CIM, SNMP, etc. As a hardware level interface, it sits at the bottom of a typical management software stack, as 
illustrated in Figure 1-, below. 


Figure 1-, IPMI and the Management Software Stack 
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1.7.3 Management Controllers and the IPMB 


Figure 1-, IPMI Block Diagram, shows the main elements of an IPMI implementation. At the heart of the IPMI 
architecture is a microcontroller called the Baseboard Management Controller, or BMC. The BMC provides the 
intelligence behind Intelligent Platform Management. The BMC manages the interface between system 
management software and the platform management hardware, provides autonomous monitoring, event logging, 
and recovery control, and serves as the gateway between system management software and the IPMB and 
ICMB. 


IPMI supports the extension of platform management by connecting additional management controllers to the 
system using the IPMB. The IPMB is an I?C-based serial bus that is routed between major system modules. It is 
used for communication to and between management controllers. This provides a standardized way of 
integrating chassis features with the baseboard. Because the additional management controllers are typically 
distributed on other boards within the system, away from the ‘central’ BMC, they are sometimes referred to as 
satellite controllers. 


Figure 1-, IPMI Block Diagram 
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By standardizing the interconnect, a baseboard can be readily integrated into a variety of chassis that have 
different management features. IPMI’s support for multiple management controllers also means that the 
architecture is scalable. A complex, multi-board set in an enterprise-class server can use multiple management 
controllers for monitoring the different subsystems such as redundant power supplies, hot-swap RAID drive 
slots, expansion I/O, etc., while an entry-level system can have all management functions integrated into the 
BMC. 


IPMI also includes ‘low-level’ DC access commands that can be used to access ‘non-intelligent’ DC devices 
(devices that don’t handle IPMI commands) on the IPMB or Private Busses accessed via a management 
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controller. The IPMB can also support SMBus slave devices, with the restriction that the SMB Alert signal is 
not supported on IPMB, and a controller that implements the IPMB protocol cannot serve as the target for an 
SMBus Modified Write Word protocol transfer from an SMBus slave. Refer to the IPMB and ICMB 
Specifications (see Reference Documents) for additional information on the IPMB and ICMB. 


1.7.4 IPMI Messaging 


IPMI uses message-based interfaces for the different interfaces to the platform management subsystem such as 
IPMB, serial/modem, LAN, ICMB, PCI Management Bus, and the system software-side “System Interface” to 
the BMC. 


All IPMI messages share the same fields in the message ‘payload’ - regardless of the interface (transport) that 
they’re transferred over. This is represented with the double-ended arrows in Figure 1-, IPMI Block Diagram, 
The same core of IPMI messages is available over every IPMI-specified interface, they’re just ‘wrapped’ 
differently according to the needs of the particular transport. This enables a piece of management software that 
works on one interface to be converted to use a different interface mainly by changing the underlying ‘driver’ 
for the particular transport. This also enables knowledge re-use: A developer that understands the operation of 
IPMI commands over one interface can readily apply that knowledge to a different IPMI interface. 


IPMI messaging uses a request/response protocol. IPMI request messages are commonly referred to as 
commands. The use of a request/response protocol facilitates the transfer of IPMI messages over different 
transports. It also facilitates multi-master operation on busses like the IPMB and ICMB, allowing messages to 
be interleaved and multiple management controllers to directly intercommunicate on the bus. 


IPMI commands are grouped into functional command sets, using a field called the Network Function Code. 
There are command sets for sensor and event related commands, chassis commands, etc. This functional 
grouping makes it easier to organize and manage the assignment and allocation of command values. 


All IPMI request messages have a Network Function, command, and optional data fields. All IPMI response 
messages carry Network Function, command, optional data, and a completion code field. As inferred earlier, the 
differences between the different interfaces has to do with the framing and protocols used to transfer this 
payload. For example, the IPMB protocol adds fields for DC and controller addressing, and data integrity 
checking and handling, whereas the LAN interface adds formatting for sending IPMI messages as LAN packets. 


1.7.5 Sensor Model 


Access to monitored information, such as temperatures and voltages, fan status, etc., is provided via the IPMI 
Sensor Model. Instead of providing direct access to the monitoring hardware IPMI provides access by 
abstracted sensor commands, such as the Get Sensor Reading command, implemented via a management 
controller. This approach isolates software from changes in the platform management hardware implementation. 


Sensors are classified according to the type of readings they provide and/or the type of events they generate. A 
sensor can return either an analog or discrete reading. Sensor events can be discrete or threshold-based. 


The different event types, sensor types, and monitored entities are represented using numeric codes defined in 
the IPMI specification. IPMI avoids reliance on strings for management information. Using numeric codes 
facilitates internationalization, automated handling by higher level software, and reduces management 
controller code and data space requirements. 


1.7.6 System Event Log and Event Messages 
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The same approach is applied to the generation and control of platform events. The BMC provides a 
centralized, non-volatile System Event Log, or SEL. Having the SEL and logging functions managed by the 
BMC helps ensure that ‘post-mortem’ logging information is available should a failure occur that disables the 
systems processor(s). 
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A set of IPMI commands allows the SEL to be read and cleared, and for events to be added to the SEL. The 
common request message (command) used for adding events to the SEL is referred to as an Event Message. 
Event Messages can be sent to the BMC via the IPMB. This provides the mechanism for satellite controllers to 
detect events and get them logged into the SEL. The controller that generates an event message to another 
controller via IPMB is referred to as an IPMB Event Generator. The controller that receives event messages is 
called the [PMB Event Receiver. 


A generic Event Receiver is a controller that accepts a Platform Event Message command over whatever media 
is connected to it, plus internally generated Event Messages. The BMC is typically the only generic Event 
Receiver in the system. 


Management Controllers that generate Event Messages must know the sensor and event type so it can place that 
information in the Event Message. This ensures that Event Messages carry important information that can be 
interpreted without requiring a-priori knowledge of the sensor, or access to the Sensor Data Record for the 
sensor. 


This is often done by *hardcoding” this relationship into the controller’s firmware. However, this approach 
binds the Sensor Type and Event Type assignment to the generation of event messages. IPMI also includes 
commands that allow the sensor and event type information to be read from the Sensor Data Record and written 
into the controller during initialization. This makes it possible to create generic management controllers that do 
not have to have hard-coded sensor types. For example, a vendor could create a device that provides a number 
of analog, threshold-based sensors that get assigned as voltage, temperature, or other sensor types according to 
the type information the system integrator placed in the SDRs for the sensors. An analog input could be 
assigned as a “+5V” sensor on one system, and a “-12V” sensor on another just by changing the SDRs. 


1.7.7 Sensor Data Records & Capabilities Commands 


IPMI’s extensibility and scalability mean that each platform implementation can have a different population of 
management controllers and sensors, and different event generation capabilities. The design of IPMI allows 
system management software to retrieve information from the platform and automatically configure itself to the 
platform’s capabilities. This greatly reduces or eliminates the need for platform-specific configuration of the 
platform management instrumentation software - enabling the possibility of “Plug and Play” platform- 
independent instrumentation software. 


Information that describes the platform management capabilities is provided via two mechanisms: capabilities 
commands and Sensor Data Records (SDRs). Capabilities commands are commands within the IPMI command 
sets that return fields that provide information on other commands and functions the controller can handle. 


Sensor Data Records are data records that contain information about the type and number of sensors in the 
platform, sensor threshold support, event generation capabilities, and information on what types of readings the 
sensor provides. 


The primary purpose of Sensor Data Records is to describe the sensor configuration of the platform 
management subsystem to system software. Sensor Data Records describe sensors; they do not instantiate 
sensors. For example, adding a new Sensor Data Record does not cause management controller firmware to 
automatically ‘grow’ or instantiate a new sensor. But they are used to describe sensors that already exist, and 
can also be used to tell software to only pay attention to a subset of the available sensors. 


Sensor data records have a limited capability to configure pre-existing sensors. There is information that an 
Initialization Agent in the BMC to enable or disable sensors and initialize thresholds. This is described more in 
the following section. 


Sensor Data Records also include records describing the number and type of devices that are connected to the 
system’s IPMB, records that describe the location and type of FRU Devices (devices that contain field 
replaceable unit information). 
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1.7.8 Initialization Agent 


SDRs can also hold default threshold values and event generation settings for sensors and management 
controllers. During system resets, the BMC performs an initialization agent function and writes these settings to 
those sensors that have ‘initialization required’ field set in their SDR. This eliminates the need for satellite 
controllers to retain their own non-volatile storage and command interfaces for default settings, and also 
provides a mechanism to retrigger any events that may have been transmitted before the BMC was ready to 
accept them. The initialization agent can also be used to assign the Sensor Type to a generic sensor. See Section 
33.6, Sensor Initialization Agent, for details on the initialization agent process. 


1.7.9 Sensor Data Record Repository 


Sensor Data Records are kept in a single, centralized non-volatile storage area that is managed by the BMC. 
This storage is called the Sensor Data Record Repository (SDR Repository). Implementing the SDR Repository 
via the BMC provides a mechanism that allows SDRs to be retrieved via ‘out-of-band’ interfaces, such as the 
ICMB, a Remote Management Card, or other device connected to the IPMB. Like most Intelligent Platform 
Management features, this allows SDR information to be obtained independent of the main processors, BIOS, 
system management software, and the OS. 


1.7.10 Private Management Busses 


A Private Management Bus (also referred to as Private Bus) is an DC bus that is accessed via a management 
controller by using IPMI commands for low-level PC access. Multiple private busses can be implemented 
behind a single management controller. IPMI supports using private busses as a mechanism for accessing 
24C02-compatible SEEPROMs (Serial Electrically Erasable Programmable ROMs) that hold FRU information. 
Private busses may also be used to provide low-level access interface for other PC or SMBus devices, though 
the IPMI specification does not cover the way such devices would be used. Each management controller can 
provide up to eight private busses. 


1.7.11 FRU Information 


The IPMI specifications include support for storing and accessing multiple sets of non-volatile Field 
Replaceable Unit (FRU) information for different modules in the system. An enterprise-class system will 
typically have FRU information for each major system board (e.g. processor board, memory board, I/O board, 
etc.). The FRU data includes information such as serial number, part number, model, and asset tag. 


IPMI FRU information can be made accessible via the IPMB and management controllers. The information can 
be retrieved at any time, independent of the main processor, BIOS, system software, or OS. This allows FRU 
information to be retrieved via ‘out-of-band’ interfaces, such as the ICMB, a Remote Management Card, or 
other device connected to the IPMB. FRU information can even be available when the system is powered down. 


These capabilities allow FRU information to be obtained under failure conditions when FRU access 
mechanisms that rely on the main processor become unavailable. This facilitates the creation of automated 
remote inventory and service applications. 


IPMI does not seek to replace other FRU or inventory data mechanisms, such as those provided by SM BIOS, 
and PCI Vital Product Data. Rather, IPMI FRU information is typically used to complement that information or 
to provide information access out-of-band or under ‘system down’ conditions. 


1.7.12 FRU Devices 
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IPMI provides FRU information in two ways: via a management controller, or via FRU SEEPROMs. FRU 
information that is managed by a management controller is accessed using IPMI commands. This isolates 
software from direct access to the non-volatile storage device, allowing the hardware implementer to utilize 
whatever type of non-volatile storage they want. 
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In order to more economically support providing FRU information on multiple platform modules, IPMI also 
allows simple 24C02-compatible SEEPROM (Serial Electrically Erasable Programmable ROM) chips to be 
used for storing FRU information. (‘24C02’-type devices are non-volatile storage devices that have a built-in 
PC-compatible interface). 


FRU SEEPROMS provide a mechanism for implementing FRU information without requiring a management 
controller on the field replaceable unit. FRU SEEPROMS can be accessed via a Private Management Bus 
connected to a management controller, or if necessary, can be placed directly on the IPMB or PCI Management 
Bus. While supported, it is generally recommended that devices with I7?C/SMBus interfaces that lack data 
integrity checks (e.g. checksums), such 24C02-type SEEPROMs, are not placed on ‘public’ busses such as 
IPMB and PCI-SMBus. This is because without data integrity checks it is possible that a misbehaved third-party 
add-in device could cause a bus ‘glitch’ that would result in an undetected error when reading or writing the 
SEEPROM. (Note: depending on the type of device, DC addressing places a limit on the number of devices that 
can be placed directly on the IPMB. Refer to the IPMB PC Address Allocation specification for more 
information.) 


1.7.13 Entity Association Records 


Entity Association Records are a special type of SDR that provides a definition of the relationships among 
platform entities. For example, an Entity Association can be set up that groups a set of individual power 
supplies into a redundant power unit. A ‘redundancy lost’ event on the power unit can then be correlated with 
the individual power supply failure. Without the Entity Association information, the ‘redundancy lost’ and 
‘power supply failed’ events would be disjoint events that could only be correlated based on a-priori knowledge 
of the system. 


1.7.14 Linkage between Events and FRU Information 


Included in the SDRs is information that indicates which system entity a sensor is monitoring (e.g. a memory 
board) and also provide a link to the FRU information for the entity. SDRs use a set of codes that specify which 
controller holds the sensor, the sensor type (e.g. temperature), the particular instance of the sensor (e.g. sensor 
#2), the sensor’s event and reading type (e.g. discrete or threshold-based), the set of events it can generate, and 
associated bit fields that indicate which specific events a sensor can produce. 


The same codes and bit fields directly map to the information that is passed in event messages and logged in the 
SEL. Thus, a SEL entry can indicate the controller, sensor, sensor type, and event type associated with the 
event. This information provides a useful level of information by itself - but when combined with SDR 
information, the event can be correlated to the entity and FRU associated with the event. Correlating an event to 
the FRU can help guide a service person to the problem area, or even be used to identify the replacement parts 
they should bring to a site. 


1.7.15 Differentiation and Feature Extensibility 


Platform management features continue to evolve. While IPMI seeks to provide a standardized interface to 
cover the majority of platform management needs, explicit provisions have been made throughout IPMI to 
support OEM differentiation and new features. Special ranges of code values and commands have been reserved 
to allow OEM sensors, events, and value-added functions to be implemented within the IPMI framework. 


1.7.16 System Interfaces 


IPMI defines three standardized system interfaces that system software uses for transferring IPMI messages to 
the BMC. In order to support a variety of microcontrollers, IPMI offers a choice of system interfaces. Using 
these interfaces is key to enabling cross-platform software. The system interfaces are similar enough so that a 
single driver can be created that supports all IPMI system interfaces. 
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The system interface connects to a system bus that can be driven by the main processor(s). The present IPMI 
system interfaces can be I/O or memory mapped. Any system bus that allows the main processor(s) to access 
the specified I/O or memory locations, and meet the timing specifications, can be used. Thus, an IPMI system 


interface could be hooked to the X-bus, PCI, LPC, or a proprietary bus off the baseboard chip set. 


The IPMI system interfaces are: 


Keyboard 
Coniroller 
Style (KCS) 


System 
Management 
Interface 
Chip 

(SMIC) 


Block 
Transfer 
(BT) 


SMBus 
System 
Interface 
(SSIF) 


The bit definitions, and operation of the registers follows that used in the Intel 
8742 Universal Peripheral Interface microcontroller. The term ‘Keyboard 
Controller Style’ reflects the fact that the 8742 interface was used as the legacy 
keyboard controller interface in PC architecture computer systems. This 
interface is available built-in to several commercially available 
microcontrollers. Data is transferred across the KCS interface using a per-byte 
handshake. 


The SMIC interface provides an alternative when the implementer wishes to 
use a microcontroller for the BMC that does not have the built-in hardware for 
a KCS interface. This interface is a three I/O port interface that can be 
implemented using a simple ASIC, FPGA, or discrete logic devices. It may 
also be built-in to a custom-designed management controller. Like the KCS 
interface, a per-byte handshake is also used for transferring data across the 
SMIC interface. 


This interface provides a higher performance system interface option. Unlike 
the KCS and SMIC interfaces, a per-block handshake is used for transferring 
data across the interface. The BT interface also provides an alternative to using 
a controller with a built-in KCS interface. The BT interface has three I/O- 
mapped ports. A typical implementation includes hardware buffers for holding 
upstream and downstream message blocks. The BT interface can be 
implemented using an ASIC or FPGA, or may be built-in to a custom-designed 
management controller. 


The SMBus System Interface (SSIF) is a low pin-count option that specifies 
accessing a BMC that is connected to the system’s SMBus host controller. 
SSIF helps support lower-cost BMC implementations by enabling an interface 
that can be used on low-cost microcontrollers in low pin-count packages. Note 
that the SSIF will typically have a much lower bandwidth to the BMC than the 
other systems interfaces, owing to the 100 kbps maximum data rate presently 
specified for SMBus. 


1.7.17 Other Messaging Interfaces 


In addition to the System Interface and IPMB, IPMI messaging can be carried over other interfaces, such as 


LAN, serial/modem, ICMB, and PCI management bus. IPMI includes a communication infrastructure that 
supports transferring messages between these interfaces as well as to the BMC. 


1.7.18 Serial/Modem Interface 
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The Serial/Modem Interface specifications define how IPMI messages can be sent to and form the BMC via a 
direct serial or external modem connection. The specification supports three connection modes that define the 


protocol for delivering IPMI messages via serial/modem: 


e Basic Mode: The IPMI messages are encapsulated with minimal additional framing and escaping for 


transport over a serial/modem connection. Basic Mode provides the highest performance but requires an 


‘IPMI-aware’ serial application. 
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e PPP Mode: The IPMI messages are encapsulated in the same RMCP format as used for LAN messages, 
but are delivered via a PPP connection. PPP mode allows remote applications to take advantage of built-in 
PPP support in the OS for things such as dialing and authentication, and provides the highest commonality 
with LAN-based software, but at the cost of lower throughput. 


e Terminal Mode: Terminal Mode defines how IPMI messages can be transferred using printable 
characters. It also includes a limited number of English ASCII text commands for doing such things as 
getting a high level system status and causing a system reset or power state change. Terminal mode is lower 
performance than Basic Mode and more limited in capabilities than both Basic Mode and PPP Mode, but 
offers a mechanism for those who are transitioning to IPMI and more sophisticated interfaces from a 
legacy, character-based environment 


1.7.19 LAN Interface 


The LAN interface specifications define how IPMI messages can be sent to and from the BMC encapsulated in 
RMCP (Remote Management Control Protocol) packets datagrams. This capability is also referred to as “IPMI 
over LAN”. IPMI also defines the associated LAN-specific configuration interfaces for setting things such as IP 
addresses other options, as well as commands for discovering IPMI-based systems. 


The Distributed Management Task Force (DMTF) specifies the RMCP format. This same packet format is used 
for non-IPMI messaging via the DMTF’s Alert Standard Forum “ASF” specification. Using the RMCP packet 
format enables more commonality between management applications that operate in an environment that 
includes both IPMI-based and ASF-based systems. More information on IPMI and ASF is provided below. 


IPMI v2.0 defines an extended packet format and capabilities that are collectively referred to as “RMCP+”. 
RMCP+ is actually defined under the IPMI-specific portion of an RMCP packet. RMCP+ utilizes authentication 
algorithms that are more closely aligned with the mechanisms used for the ASF 2.0 specification. In addition, 
RMCP+ adds data confidentiality (encryption) and a ‘payloads’ capability. 


1.7.19a Payloads 


“Payloads” are a capability specified for RMCP+ that enable an IPMI session to carry types of traffic that are 
in addition to IPMI Messages. Payloads can be ‘standard’ (defined in the IPMI specifications) or ‘OEM’ 
(specified by an OEM or other organization). Standard payload types include IPMI Messages, messages for 
session setup under RMCP+, and the payload for the “Serial Over LAN” capability introduced in IPMI v2.0. 


A BMC implementation can allow a payload to be activated (launched) on the same IPMI session that a 
remote user connected to the BMC over, or the BMC can require that the remote console establish a separate 
session for the payload. This enables an implementation to off-load the payload processing to another device, 
if desired. 


1.7.20 Serial Over LAN (SOL) 


Serial Over LAN (SOL) is the name for the redirection of baseboard serial controller traffic over an IPMI 
session. This can be used to enable asynchronous serial-based OS and pre-OS communication over a connection 
to the BMC. SOL is specified in Section 15, Serial Over LAN. SOL provides can be used to provide a user at a 
remote console a means of interacting with serial text-based interfaces such as operating system command-line 
interfaces, serial redirected BIOS interfaces, and serial text-based applications over and IPMI LAN session. A 
single remote console application can use SOL to simultaneously provide LAN access to IPMI platform 
management and serial text redirection under a unified user interface. SOL is implemented as a payload type 
under the IPMI v2.0 *RMCP+” protocol. Access privileges for SOL are managed under the same user 
configuration interfaces that are used for IPMI management. This simplifies the creation of configuration 
software, remote management applications, and cross-platform configuration utilities. 
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1.7.21 IPMI and ASF 


IPMI and ASF are complementary specifications that can provide platform management in a ‘pre-boot’ or ‘OS 
absent’ environment. IPMI uses a management microcontroller as the main element of the management system, 
whereas ASF presently focuses on having an ‘alert sending device’ - typically the network controller - polling 
devices on the motherboard and autonomously generating alerts. As of this writing, ASF’s scope primarily 
covers the way an alert sending device polls sensor devices and sends alerts, and the specification of “LAN? 
commands for discovering RMCP-based systems and performing emergency reset and power off actions. 


This includes the supporting specification of SMBus interfaces to ‘ASF Sensor Devices’ that can be polled by 
the alert sending device, the specification of the RMCP packet format, and the specification of SMBus-based 
commands that can be used to send a ‘push’ alert via an alert sending device. 


While somewhat of an oversimplification, ASF may be considered to be scoped for ‘desktop/mobile’ class 
systems, and IPMI for ‘servers’ where the additional IPMI capabilities such as event logging, multiple users, 
remote authentication, multiple transports, management extension busses, sensor access, etc., are valued. 
However there are no restrictions in either specification as to the class of system that the specification can be 
used. Le. you can use IPMI for desktop and mobile systems and ASF for servers if the level of manageability 
fits your requirements. 


IPMI and ASF share a number of formats, data structures, and enumerations. It is expected that this will 
continue to grow. 


e Shared management packet format: IPMI uses ASF ‘RMCP’ packet format for delivering IPMI messages 
over LAN and PPP and ASF messages for LAN discovery. The RMCP format includes a message class 
explicitly for IPMI use. 


e Common LAN Alert Format: Both generate LAN Alerts using the IPMI PET (Platform Event Trap) 
Specification for SNMP Traps 


e Common Flags for boot control: IPMI uses a superset of the boot flags defined in ASF. 


e Common enumerations for sensor types and event types: ASF uses the IPMI enumerations for sensor and 
event types. These values are used in Alerts and ASF Sensor Device Status. 


e Common BIOS progress codes: IPMI uses ASF BIOS Error and Progress codes. 


e Hardware: IPMI management controllers and ASF alert sending devices can both use ASF Sensor Devices. 
In an IPMI application these can be place on private management busses and polled by the BMC, they can 
also be used on the PCI management bus. In an ASF application, the devices would typically always be on 
the PCI management bus or main SMBus and polled by the Network Controller(s). 


1.7.22 LAN Alerting 


IPMI supports LAN Alerting in the form of SNMP Traps that follow the Platform Event Trap (PET) format. 
(Refer to [PET] for more information.) SNMP Traps are typically sent as unreliable datagrams. However, IPMI 
includes a PET Acknowledge and retry options that allows an IPMI-aware remote application to provide a 
positive acknowledge that the trap was received. 


1.7.23 Serial/Modem Alerting and Paging 
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The IPMI specification supports several options for alerting over a serial/modem connection: 
e Dial Page: Sending a numeric page by using an external modem to generate ‘touch tones’. 
e TAP Page: The BMC connects to a TAP 1.8 paging service and delivers an alphanumeric page. 


e PPP Alert: The BMC connects to a remote LAN via PPP and delivers a PET trap to a specified IP address. 
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1.7.24 Platform Event Filtering (PEF) 


Platform Event Filtering (PEF) provides a mechanism for configuring the BMC to take selected actions on 
event messages that it receives or has internally generated. These actions include operations such as system 
power-off, system reset, as well as triggering the generation of an alert. 


The BMC maintains an event filter table that is used to select which events trigger an action and which actions 
to perform. Each time the BMC receives an event message (either externally or internally generated) it 
compares the event data against the entries in the event filter table. The BMC scans all entries in the table and 
collects a set of actions to be performed as determined by the entries that were matched. 


1.7.25 Call Down Lists and Alert Policies 


The IPMI specification allows an implementation to support configurable alert policies that determine how an 
alert will be processed. These can be used to create a ‘call down list’ of different destinations that an alert gets 
sent to. Alert policies can have destinations of different types and on different channels. For example, a policy 
could be defined to first try to send an alert to LAN address ‘A’, and if that fails send it to LAN address ‘B’, and 
then send a Dial Page via the modem, and if that fails, a TAP page. 


IPMI allows the alert destinations to be configured in any order. I.e. you can pick whether an alert goes out via 
serial/modem first, or via LAN first. The main limitation comes from the number of policy entries that a given 
implementation supports. 


1.7.26 Channel Model, Authentication, Sessions, and Users 


IPMI v1.5 incorporates a common communication infrastructure referred to as the ‘Channel Model’. This is an 
extension of the channels that were used as part of messaging in IPMI v1.0. 


Channels provide the mechanism for directing the routing of IPMI messages between different media 
connections to the BMC. A channel number identifies a particular connection. For example, 0 is the channel 
number for the primary IPMB. Up to nine total channels can be supported (the System Interface and primary 
IPMB, plus seven additional channels with a media type assigned by the implementer.) Channels can thus be 
used to support multiple IPMB, LAN, Serial, etc., connections to BMC. 


Channels can be session-based or session-less. A session is used for two purposes: As a framework for user 
authentication, and to support multiple IPMI Messaging streams on a single channel. Session-based channels 
thus have at least one user ‘login’ and support user and message authentication. Session-less channels do not 
have users or authentication. LAN and serial/modem channels are examples of session-based, while the System 
Interface and IPMB are examples of session-less channels. 


In order to do IPMI messaging via a session, a session must first be activated. The act of activating a session is 
one of authenticating a particular user. This is accomplished using a ‘challenge/response’ mechanism, where a 
challenge is requested using a Get Session Challenge command, and the signed challenge returned in an 
Activate Session command. 


The specification supports different algorithms for the signature - these are referred to as Authentication Types. 
Authentication Types include ‘none’, ‘straight password’, the MD2 and MDS message-digest algorithms, etc. 
For consistency, session-based channels always use the Get Session Challenge and Activate Session commands 
even if Authentication Type is ‘none’. (In this case, dummy values are used for the signatures.) 


A session has a Session ID that is used for tracking the state of a session. The Session ID mechanism allows 
multiple sessions to be able to be simultaneously supported on a channel. 


The message signature, Session ID, and other session related information is separate from the actual IPMI 
message content. Thus, a packet carrying an authenticated IPMI message can be thought of as being comprised 
of a ‘Session Packet’ that includes the session-specific fields and carries an IPMI message as its payload. 
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The concept of user is essentially a way to identify a collection of privilege and authentication information. 
User configuration is done on a per channel basis. This means that a given user could have a different password 
and set of privileges for accessing the BMC via a LAN channel than via a serial channel. 


Privilege Levels determine which IPMI commands a given user can execute over a given channel. 


Privilege Limits set the maximum privilege level that a user can operate at. A user is configured with a given 
maximum privilege limit for each channel. In addition there is a Channel Privilege Limit that sets the maximum 
limit for all users on a given channel. The Channel Privilege Limit takes precedence over the privilege 
configured for the user. Thus, a user can operate at a privilege level that is no higher than the lower of the User 
Privilege Limit and the Channel Privilege Limit. 


1.7.27 Standardized Watchdog Timer 


Watchdog Timer capabilities have been commonly deployed in Enterprise-class servers. IPMI provides a 
standardized interface for a system Watchdog Timer. This timer can be used for BIOS, OS, and OEM 
applications. The timer can be configured to automatically generate selected actions when it expires, including 
power off, power cycle, reset, and interrupt. The timer function can also automatically log the expiration event. 
Setting ‘0’ for the timeout interval allows the timeout action to be initiated immediately. This provides a means 
for devices on the IPMB, such as Remote Management Cards, to use the Watchdog Timer to initiate emergency 
reset and other recovery actions dependent on the capability of the timer. 


1.7.28 Standardized POH Counter 


This is an optional counter to return a counter value proportional to the system operating (SO) power-on hours. 


1.7.29 Firmware Firewall 


“Firmware Firewall” is the name for a capability that is primarily provided to enable a BMC implementation to 
block certain configuration, messaging, and write operations from being done from the System Interface. This is 
done primarily to provide a way prevent local software from unintentionally or maliciously setting values or 
performing actions that could affect multiple nodes in a modular “blade” chassis, but can be used in BMC 
implementations in ‘standalone’ systems as well. Firmware Firewall provides mechanisms that enable the BMC to 
block IPMI commands and functions from being accessed from a given interface, and a set of “command 
discovery” commands that let software discovery and configure which commands and functions are available. 


1.7.30 Command and Function Discovery 


The ‘command discovery’ commands that support Firmware Firewall can be implemented separately as a way of 
enabling software to more efficiently discover command support, and as a way to assist automated ‘conformance 
testing’ of IPMI implementations. Without the command discovery commands, IPMI utilizes several mechanisms 
that software can use to determine what commands and functions are supported on a given management 
controller. Some commands are simply mandatory, other commands and IPMI functions are discoverable via the 
Sensor Data Records, ‘capabilities’ commands, or bit fields in responses. Remaining functions are discovered by a 
‘test for support’ approach - where software trys issuing the command to see if it is implemented or not. Support 
for some functions is also implied by whether or not other commands are present because they’re part of a set. For 
example, if a “Set Configuration Parameters” command is supported, then it can be inferred that the 
corresponding “Get Configuration Parameters” will also be supported. The command discovery commands, 
however, enable a BMC to optionally provide a ‘centralized’ way of reporting command and function support, 
rather than the ‘distributed’ and ‘test based’ mechanism that is the default. 
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1.7.31 IPMI Hardware Components 


IPMI provides very few specifications for the actual hardware components used to implement the platform 
management hardware. IPMI seeks to ‘standardize the interface, not the implementation’. IPMI was designed so 
that it can be implemented with ‘off-the-shelf? components. Thus, IPMI does not require specific 
microcontrollers to be used for management controllers, nor special ASICs or proprietary logic devices. As long 
as the interface, timing and (in the case of IPMB and ICMB) electrical specifications are met, the choice of 
components is up to the implementer. It is mandatory to implement a system interface that is compatible with 
one of the three specified system interfaces. 


1.7.32 Configuration Interfaces 


IPMI provides standardized interfaces and commands for configuring the platform management subsystem. 
This enables cross-platform software to Sensor Data Records are an example of the interface for configuring 
sensor population and behavior on a system. There are also commands for configuring capabilities such as LAN 
and serial/modem remote protocols, user passwords and privilege levels, Platform Event Filtering, alert 
destinations, and others. 


Unless otherwise specified, changes to parameters are required to take effect for the next use. For example, 
parameters that affect user access or session operation must take effect for the next time a remote console 
attempts to connect to the system. In some implementations, changes to configuration parameters may take 
effect immediately. Thus, a remote application should be careful when setting parameters that could cause the 
application to become disconnected from the BMC. 


For the purpose of conformance checking, up to 5 seconds will be allowed between the time a parameter is 
changed to when it must have taken effect. 


It is recognized that there are race conditions where a session may already be in the process of being established 
before the change can be propagated. It is recommended that a BMC implementation takes steps to ensure that 
parameters are used consistently. This specification does not define a specific mechanism, but here are some 
possible approaches. An implementation could terminate a session in progress if the user’s parameters change 
while the session is being established. Alternatively, an implementation could ‘snap shot’ the user’s 
configuration at the time the session is being established and only allow a session to be established if the given 
user’s configuration has been unmodified in the last 5 seconds. 


1.8 IPMI and BIOS 


The level of interaction between BIOS and IPMI is greatly dependent on the implementation and number of 
optional capabilities that are to be supported. It is possible to have an IPMI implementation that does not require 
any BIOS support, other than that required to meet any applicable ACPI or Plug ‘N Play requirements for 
reporting the I/O and/or interrupt resources used by the IPMI system interface. 


In some implementations, BIOS may be responsible for the initialization or startup of certain functions in the 
management controllers, such as setting the initial timestamp time in the SEL and/or SDR devices. BIOS may also 
perform tests of the platform management hardware and management controllers during POST. 


It is recommended that BIOS include provisions for checking and reporting on the basic health of BMC by 
executing the Get Self Test Results command and checking the result. 


It’s expected that most implementations will provide BIOS features that take advantage of IPMI. For example, it 
is expected that many implementations will use IPMI to log POST errors, or to log ‘system boot’ events so that 
events can be tracked relative to the last boot time. Another expectation is that many systems utilize the IPMI 
Watchdog Timer function with BIOS. 


With IPMI v1.5, the BIOS can share in additional capabilities. For example, IPMI v1.5 defines a new LAN-based 
interface. The BIOS can help keep the BMC updated with the LAN IP Address assignment. IPMI v1.5 also 
includes a serial/modem interface with support for a capability called ‘serial port sharing’ in which the serial 
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controller can be shared between the BMC and BIOS-based serial console redirection. There is also a set of ‘boot 
flags’ that BIOS can read to direct its operation following a system management initiated reset, power cycle, or 
power up. 


1.9 System Management Software (SMS) 


The Management Controllers, Sensors, SEL information, SDR information, etc., are of limited value without 
System Management Software to interpret, handle, and present the information. Platform management is only a 
subset of systems management. System Management Software takes platform management information and links 
it into other aspects of systems management, such as software management and distribution, alerting, remote 
console access, etc. 


With respect to the platform management architecture and this specification, System Management Software: 


e Polls the System Event Log for new Event information, acting on it as appropriate. This may include 
taking actions such as sending alerts on the network, presenting a local ‘pop-up’ message, shutting 
down an application, consolidating the information with other ‘system log’ data, etc. System Critical 
Events are primarily communicated to system management software using the System Event Log as a 
‘mailbox’ between the originator of the Event Message and the system management software. 


e Manages the System Event Log. The SEL may contain ‘critical’ event information that should not be 
lost. Therefore, the SEL device will not automatically clear the SEL if it gets full. This operation is 
based on the assumption that it is the first events that are most indicative of the root cause of a 
problem, and that later events may be ‘side-effects’ which, if the SEL were implemented as a ‘FIFO’ 
could cause the ‘root cause’ events to get lost. Instead, System Management Software has the 
responsibility for determining when SEL entries should be cleared. System Management Software can 
migrate the SEL contents to disk, to the system’s event log, or even to remote storage as desired. 


e Reads and interprets the SDR Repository information. System Management Software uses this 
information to determine the sensor population and capabilities. The Sensor Data information can also 
be presented to provide a description of the system’s manageability features. 


e ‘Polls’ sensors. System Management Software takes the SDR information and uses it to access the 
sensors, either in a polled or ‘on demand’ basis, to monitor and present the system’s current health and 
status. Note that whenever possible, System Management Software should rely on event generation for 
detecting error conditions, and avoid the overhead associated with polling. ‘Normal’ health status does 
not generally need to be polled, but would be delivered ‘on demand’. 


e Potential Event Message Source. System Management Software can also send Event Messages to get 
events added to the System Event Log. This allows SMS to record information that may be required 
for ‘post-mortem analysis’ should it become necessary for System Management Software to shut- 
down, power-cycle, reset, or otherwise ‘off line’ the system as a response to a system event. The SEL 
should be reserved for ‘critical’ hardware-related errors. The majority OS and software errors should 
not be written to the SEL. Candidate errors for the SEL are errors that block normal ‘in-band’ 
management mechanisms. 


1.10 SMI Handler 


Not all platform management events come through management controllers or from system software. Some events 
come from baseboard interrupts. This may include platform events such as correctable and uncorrectable ECC 
errors, critical NMIs (Non-maskable Interrupts) such as PCI PERR (parity error), PCI SERR (system error), bus 
timeout interrupts, etc. In some implementations, the platform management hardware maps these ‘critical 
interrupts’ to the system SMI (System Management Interrupt) signal. The SMI Handler runs, and, as part of 
handling these critical interrupts, generates an Event Message to cause the event to get logged in the SEL. The 
SMI Handler can also take autonomous, ‘emergency’ action, such as powering off or resetting the system, or 
propagating an NMI to the operating system. 


24 


Intelligent Platform Management Interface Specification 


The SMI Handler is typically a routine that is loaded and initialized into a protected area of memory by the BIOS. 
SMI is the highest priority non-maskable interrupt in the system. When asserted, it switches the processors into 
‘System Management Mode’ (SMM). Upon entry into SMM, the processor state is saved and a memory 
configuration is entered where the SMI Handler has full access to system memory and I/O space. This allows the 
SMI Handler to implement its management functions in an OS-independent manner. The key aspect to this being 
that the SMI Handler code will run even if the OS is ‘hung’. This makes it ideal for implementing certain critical 
and emergency management functions. 


The explicit interface and functionality between an SMI Handler and the BMC is implementation dependent and 
is not covered by this specification. The implementation of system-specific communication interfaces can be 
aided using the OEM bits and flags in the BMC-system interface commands. 
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1.11 


Overview of Changes from IPMI v1.0 


This section assumes familiarity with the IPMI v1.0 specification. If you’re new to IPMI, you can skip ahead to 
the next section. This is not intended to be a complete “to the bit” list of all the changes, but is provided as a guide 
for understanding what’s involved in moving to support IPMI v1.5. 
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Most commands that have version numbers had their version numbers rev'd to 51h for IPMI 1.5 


The Get Device ID command was extended a couple of optional firmware revision bytes, per NEC request. 
Just display them as hex-ASCH. 


The IPMI sensor commands are the same as in v1.0, though a small amount of typo corrections and additional 
clarifications have been made in those sections. 


The IPMI watchdog commands are backward compatible with IPMI v1.0. A previously reserved bit has been 
defined as a new ‘don’t stop’ bit that allows the watchdog timer to be reconfigured without stopping it. 


The IPMI v1.0 event commands are the same. A couple of new event commands, Set/Get Last Processed 
Event have been added to allow someone using the new IPMI v1.5 PEF capability to set or determine whether 
or not PEF has pending events to process. 


Sensor Event/Reading Type codes - The POST Error sensor is now called "System Firmware Progress" and 
includes new offsets for POST errors and progress the follow the DMTF ASF specification. There's also a 
new 'Management Subsystem Health' sensor type, 28h. Please check the Sensor Event/Reading Type code 
table for any other changes. 


The SEL Event Record format is the same except that four previously reserved bits now hold a channel 
number, and the SEL Record version "EvMRev" field goes from 3h to 4h. It’s possible that two events would 
be identical except for the channel number field. Software that handles or displays events should interpret the 
channel number field in order to differentiate between events coming from different channels. 


The SDRs are the same with the exception of the version number and a field changes to accommodate a 
necessary fourth bit for the channel number. This change affected SDRs O1h, 02h, 10h, 11h and 12h. The 
addition of a channel number in the Type 12h SDR caused the two bytes following to get pushed down. 


The Entity Instance value in the Entity Association Record has been split into two ranges: one for 'system 
relative’ IDs and another for 'device relative’ IDs. Most implementations will be able to use their existing 
Entity Instance assignments since the lower range of values are for the 'system relative' Entity Instance 
values, which map to the IPMI v1.0 definition of the Entity Instance value. 


SDR Type 14h is being deprecated. IPMI 1.5 systems and software should not use SDR Type 14h. Software 
should use the new Get Channel Info command instead. 


The SEL Event Record format is the same except that four previously reserved bits now hold a channel 
number, and the SEL Record version "EvMRev" field changes from 3h to 4h. 


The IPMB message format remains the same. 


The Send Message command is backward compatible with v1.0 with respect to using it to access the IPMB. 
Le. you don't need to make any changes to access the IPMB. 


The Master Write/Read PC has had the “I2C” dropped from the name. It is now the Master Write/Read 
command. This command is backward compatible with IPMI v1.0. Reserved bits 7:4 in byte one have 
become a Channel ID, but Oh is when accessing the IPMB or private management busses as in IPMI v1.0. A 
non-zero channel value would only be used for accessing additional IPMBs or a PCI Management Bus. 


The read/write FRU commands are the same. 
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2. Logical Management Device Types 


The Intelligent Platform Management architecture is comprised of a number of ‘logical’ management devices. These 
are implemented by and within the ‘physical’ system elements such as the management controllers, DC bus, system 


ASICs, etc. 


Each ‘logical device’ type represents the definition of a particular set of mandatory and optional commands. For the 
purposes of this specification, the logical management devices are: 


IPM Device 


Sensor Device 


SDR Repository Device 


SEL Device 


FRU Inventory Device 


Event Receiver Device 


Event Generator Device 


Application Device 


PEF Device 
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Intelligent Platform Management device. This represents the ‘basic’ intelligent 
device that responds to the platform sensor and event interface messages. All 
Intelligent Platform Management devices on the IPMB are expected to respond to 
the mandatory ‘IPM Device’ commands. These are also referred to as the ‘global’ 
commands. Management Controllers that communicate via compatible messages 
to the system are also considered IPM devices. 


The Sensor Device is a device that provides the command interface to one or more 
sensors. Sensor Devices provide a set of commands for discovering, configuring 
and accessing sensors. 


The SDR Device is the logical management device that provides the interface to 
the Sensor Data Records (SDR) for the system. The SDR Device provides a set of 
commands for storing and retrieving Sensor Data Records. 


The SEL Device is the logical management device that provides the interface to 
the System Event Log for the system. The SEL Device provides a set of 
commands for managing the System Event Log. 


The FRU Inventory Device provides the interface to a particular module’s FRU 
Inventory (serial number, part number, asset tag, etc.) information. There will 
typically be one set of FRU Inventory information for each major module in the 
system. There can be just as many FRU Inventory Devices providing access to that 
information. The Primary FRU Inventory Device for a given management 
controller is defined as the device that contains the information about the FRU that 
holds the management controller itself. 


The Event Receiver Device accepts and acknowledges Event Request Messages. 
The normal action for the Event Receiver Device is to then pass the Event 
Message to the SEL Device for logging. An [PMB Event Receiver refers to an 
Event Receiver that accepts Event Messages from the IPMB. 


The Event Generator Device represents the functionality that is used to deliver 
Event Messages to the Event Receiver Device. The Event Generator Device 
includes commands to allow configuration of Event Message delivery. The term 
IPMB Event Generator refers to the capability to generate an Event Message on 
the IPMB. The BMC is typically an IPMB Event Receiver, but not an IPMB Event 
Generator. 


A physical instantiation of an Intelligent Platform Management device will most 
likely have some ‘device specific’ functionality that it implements that falls 
outside the ‘standard’ sensor and event functions. This functionality is referred to 
as the devices ‘Application’ functionality. Commands that address this 
functionality are viewed as being handled by an ‘Application’ logical device. 


This logical device represents the functions associated with comparing an event 
message against a set of selectable ‘event filters’ and generating a selectable action 
on a match. 
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Alert Processing Device This logical devices represents the functions associated with queuing up and 
processing alerts, and alert policies that determine which destinations an alert will 
be sent to. 


Chassis Device This chassis control device represents functions associated with recovery control 
actions such as power on/off, power cycle, reset, diagnostic interrupt, chassis 
identification indicator, and system boot. 


Message Handler This logical device represents the functions associated with configuration and 
operation of message authentication and routing, both internal to the BMC and 
among the different interfaces to the BMC. 


The Intelligent Platform Management Bus can be considered as defining other ‘logical’ devices as well, such as the 
‘Bridge Device’ for the Intelligent Chassis Management Bus (ICMB). Refer to the Intelligent Platform Management 
Bus Protocol Specification for more information. 
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Figure 2-, Intelligent Platform Management Logical Devices 
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3. Baseboard 


Management Controller (BMC) 


The management architecture can be implemented by centralizing the most common functions into a ‘central’ 
management controller in the system. This controller is often called the Baseboard Management Controller, or 
BMC. In some system implementations, the BMC may be the only management controller. The BMC typically 
provides the following platform management functions: 


System Interface 


Message Handler 


SEL Interface 


Event Generator 


SDR Repository Interface 


IPMB Interface 


IPMB Event Receiver 


Private Bus Controller 


FRU Information 
Interface 


OEM Commands 
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The BMC provides the System Interface to the IPMI-based platform management 
subsystem. The System Interface is the interface through which system software 
sends and receives messages to and from the BMC. 


The BMC provides functions for routing messages between the different interfaces, 
including the System Interface, IPMB, serial/modem, LAN, etc. The Message 
Handler may also be thought of as where shared messaging functions for configuring 
channel characteristics and user privileges reside. 


The BMC provides the interface to the System Event Log (SEL). The BMC allows 
the SEL to be accessed both from the system side, but also from the Intelligent 
Platform Management Bus and other external interfaces to the BMC. 


The BMC itself will typically be responsible for monitoring and managing the system 
board. For example, monitoring baseboard temperatures and voltages. As such, the 
BMC will also be an Event Generator internally, sending the Event Messages that it 
generates internally to its Event Receiver functionality. Note the BMC is not 
typically and IPMB Event Generator. That is, it does not typically issue Event 
Messages onto the IPMB. 


The BMC will also provide the interface to the SDR (Sensor Data Record) 
Repository. As with the System Event Log, the BMC allows the records in the SDR 
Repository to be accessed either via the Intelligent Platform Management Bus or via 
the system interface. 


A BMC will typically support an IPMB connection. The IPMB enables the BMC to 
accept IPMI request messages from other management controllers in the system. The 
IPMB provides a simple integration point for connecting the ‘chassis’ management 
features to the baseboard management. The IPMB can also provide a connection that 
enables add-in cards to get access to the platform management subsystem. 


A BMC that includes IPMB Interface support also provides the capability for system 
software to send and receive messages to and from the IPMB using the BMC as a 
kind of communication controller. 


When an IPMB is implemented, the BMC serves as the primary IPMB Event 
Receiver for the system. Event Messages can be sent to the BMC from the system or 
from other controllers the IPMB. 


FRU SEEPROMS may be provided on Private Management Busses behind the BMC. 
The BMC can server as a communication controller that provides access to Private 
Management Busses and provide access to FRU SEEPROMs and other non- 
intelligent devices via the Master Write-Read command. 


The BMC provides access to FRU information for the base system board. The FRU 
information for the board holding the BMC is obtained by sending FRU Commands 
to the BMC’s LUN 00b. 


A BMC implementation can include special support for OEM-unique features and 
functions. One way of accomplishing this is by implementing OEM commands 
through the IPMI messaging interfaces. 


Watchdog Timer 
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IPMI defines common command interfaces for configuring and accessing a watchdog 
timer function in the BMC. This timer can be used as an aid in monitoring the health 
of BIOS and system software. The watchdog timer can be used by different types of 
software such as BIOS, pre-boot, OS, and system management software. Once started 
the timer must be periodically reloaded by software in order to keep it from expiring. 
If software ceases to run, the timer will expire and generate a timeout action. 


The IPMI definition allows different actions to be selected to occur on a watchdog 
timeout. This includes reset, power off, power cycle, etc. and a ‘pre-timeout 
interrupt’ option that, if provided, can be used to generate a system interrupt shortly 
before the timeout. The definition includes ‘timer use’ fields that keep track of what 
type of software (BIOS, OS, System Management Software, etc.) started the timer. 
The timeout action and ‘timer use’ information can be automatically logged to the 
SEL when the timeout occurs. This provides a record of when the timeout occurred, 
what software was using the timer, and what action was taken. 


In addition, a BMC may implement additional functions for messaging and alerting, including: 


Serial/Modem Interface 


Serial Port Sharing 


LAN Interface 


PCI Management Bus 
Interface 


Platform Event Filtering 
(PEF) 


Alert Processing 


The BMC can provide a serial/modem interface that allows it to receive IPMI 
messages over a serial connection to the BMC. 


Serial Port Sharing is a separate capability that works in conjunction with the 
serial/modem interface. Serial Port Sharing provides a mechanism where the BMC 
can control logic that allows a single serial connector to be shared between a serial 
controller on the baseboard and a serial controller for the BMC. 


From the IPMI point-of-view, the interface to the network controller is dedicated to 
the BMC. That is, there are no special commands for coordinating the sharing of the 
network controller between system software access and BMC access, as there are 
with Serial Port Sharing. If the network controller is shared between system software 
and the BMC, this is generally accomplished via special hardware in the network 
controller that enable BMC traffic and system traffic to be interleaved. 


The BMC can implement a PCI Management Bus Interface that enables the BMC to 
accept IPMI request messages from add-in cards that plug into a PCI slot. The PCI 
management bus and IPMB can serve complementary roles. The IPMB providing a 
mechanism for integrating management functions between baseboard and chassis 
board functions, while the PCI Management Bus connection can be used to support 
add-in cards. This division allows the inter-board management communications to be 
kept separate from add-in card communications. 


Platform Event Filtering is an ability for the BMC to perform a configurable action 
based on an event, by matching the event against a set of ‘event filters’. The actions 
that a BMC can elect to implement include power off, reset, power cycle, generate 
diagnostic interrupt, and send an alert. 


IPMI v1.5 supports the ability for a BMC to deliver alerts such as SNMP Traps in the 
Platform Event Trap (PET) format, over media such as LAN and PPP, plus the ability 
to perform numeric and/or alphanumeric paging via a serial/modem connection. Alert 
processing includes the ability to support sending alerts to multiple destinations, and 
to cluster destinations into sets called ‘Alert Policies’. Enabling alert policies with 
PEF makes it possible to configure the system so critical events are delivered to 
destinations in a ‘high priority’ alert policy, while non-critical events would go to 
destinations in a ‘low priority’ alert policy. 
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3.1 Required BMC Functions 


The following table summarizes the major required and optional functions for an IPMI-conformant BMC. 


Table 3-, Required BMC Functions 


IPM Device M The BMC must implement the mandatory IPM Device commands. If an IPMB 
is provided, the mandatory commands must be accessible from the IPMB 
unless otherwise noted. 

System Interface M The implementation must provide BMC access via one of the specified IPMI 
system interfaces. 

M 


SDR Repository The BMC must provide a SDR Repository to hold Sensor, Device Locator, 
and Entity Association records for all sensors in the platform management 
subsystem. This does not need to include SDRs for sensors that only 
generate events. If the SDR Repository is writable, it is recommended that at 
least 20% additional space is provided for add-in platform management 
extensions. 

The SDR Repository must be accessible via the system interface. If an IPMB 
is provided, the SDR Repository must be readable via that interface as well. 
SDR update via the IPMB interface is optional. 

SDR Repository access when the system is powered up or in ACPI ‘S1’ sleep 
is mandatory, but access when the system is powered down or in a >S1 
sleep state is optional. 


IPMB Interface The IPMB is highly recommended, but optional. The BMC must provide the 
system interface to the IPMB. If an IPMB is implemented, at least one of the 
specified IPMB connectors must be provided. Refer to the IPMB Protocol 
specification for connector definition. In addition the BMC must implement a 
message channel that allows messages to be sent from the IPMB to the 
system interface, and vice-versa, and any other mandatory IPMB support 
functions and commands. 


Watchdog Timer The BMC must provide the standardized Watchdog Timer interface, with 
support for system reset action. Certain functions within the Watchdog Timer 
are optional. Refer to the sections on the Watchdog Timer for information. 


Event Receiver The BMC must implement an Event Receiver function and accept Event 
Messages via the system interface. If an IPMB is provided, the Event 
Receiver function must also accept Event Messages from the IPMB. Event 
Receiver operation while the system is powered up or in ACPI ‘S1’ sleep is 
mandatory, but operation when the system is powered down or ina -S1 
sleep state is optional. 


SEL Interface The BMC must provide a System Event Log interface. The event log must 
hold at least 16 entries. SEL access must be provided via the system 
interface. The SEL must be fully accessible via all mandatory SEL commands 
through all supported interfaces to the BMC whenever the system is powered 
up or in ACPI 'S1' sleep state. SEL read access is always mandatory 
whenever the BMC is accessible, and through any interface that is 
operational, regardless of system power state. . 

FRU Inventory The BMC must provide a logical Primary FRU inventory device, accessible 

i via the Write- and Read FRU Data commands. The FRU Inventory Device 
Info command must also be supported. It is highly recommended that all 
other management controllers also provide a Primary FRU inventory device. 
(This was optional in IPMI v1.0.) 


Initialization Agent The initialization agent function is one where the BMC initializes event 
generation and sensors both internally and on other management controllers 
according to initialization settings stored in the SDR for the sensor. 


Sensors The BMC can provide sensors. A typical server BMC would provide sensors 
for baseboard temperature, voltage, and chassis intrusion monitoring. 
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Function wo 


Internal Event The BMC must generate internal events for the Watchdog Timer. It is highly 

Generation recommended that sensors generate events to eliminate the need for system 
management software to poll sensors, and to provide “post-mortem” failure 
information in the SEL. Internal event generation for sensors is optional, but 
highly recommended - particularly for ‘environmental’ (e.g. temperature and 
voltage) sensors. 


The BMC could be designed to accept the Set Event Receiver command to 
allow it to be set as an IPMB Event Generator and send its event messages 
to another management controller. This would primarily be used for 
development and test purposes. 


The BMC supports a connection to a PCI Management bus through which the 
BMC can send and receive IPMI Messages. System software can also 
access the PCI Management Bus by sending commands to the BMC via the 
System Interface. 


Ability for the BMC to send and receive IPMI Messaging over LAN 


Ability to send an Alert over the LAN 


External Event 
Generation 


PCI Management Bus 
Interface 


LAN Messaging 
LAN Alerting 


asynchronous serial connection to the BMC. If Serial Messaging is supported, 
the following sub-functions apply: 

Basic Mode is a type of message framing used for IPMI messaging over a 
serial connection. Basic Mode support is required if Serial Messaging is 
supported. 


PPP Mode is support for using PPP protocols and framing for IPMI 
Terminal Mode is a mechanism for IPMI messaging over serial using 
printable ASCII characters. Terminal mode also supports a limited number of 
text commands to support legacy ‘text based’ environments. 
Direct Connect Mode is support for IPMI messaging over a serial connection 
without going through a modem. Direct connect mode is mandatory as part of 
Serial Messaging. 
Modem Connect Mode is support for IPMI messaging over a serial 
connection through a TIA-602-compatible modem, or via modem circuitry that 
can work with the IPMI commands defined for modem communication. 
Bridging Support The ability to transfer IPMI request and response messages between two 
interfaces connected to the BMC. 
The following support is required if the corresponding interfaces are 
supported: 
e  seria/modem <> IPMB 
e  serial/modem €> System Interface 
e LAN <> IPMB 
e LAN €> System Interface 
Recommended: 
e ` serial/modem €> PCI Management Bus 
e LAN €> PCI Management Bus 
Optional: 
all other combinations, e.g. serial/modem <> LAN 


Dial Page Ability to perform a numeric page by dialing. Typically accomplished using an 
external modem. 


PPP Alerting O Ability for the BMC to connect to a system 
Platform Event Filtering and Serial Messaging with PPP Mode are required if 
PPP Alerting is implemented. 


Basic Mode 


PPP Mode 


Terminal Mode 


Direct Connect Mode 


Modem Connect Mode 


Serial Messaging 7 Serial messaging is the capability of performing IPMI Messaging over an 
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Callback Callback represents the ability for the BMC to be directed to dial up a 
selected or pre-configured destination to establish an IPMI Messaging 
session. Callback requires Serial Messaging with Modem Connect Mode. 


Basic Mode Callback M Required if Callback is supported. BMC uses Basic Mode for IPMI messaging 
after connecting to specified destination. 
PPP Mode Callback BMC uses PPP Mode for IPMI messaging after connecting to specified 
destination. 


Mode and PPP Mode Callback support are required if aoe Callback is 
implemented. 
Platform Event Filtering Ability for BMC to perform a selectable action on an event. This capability is 
(PEF) and Alert Policies mandatory if paging or alerting is supported. Certain actions within PEF are 
optional. Refer to the sections on PEF for information. The Alert action and 
Alert Policies are mandatory if serial/modem or LAN alerting is supported. 


CBCP Callback E BMC supports Microsoft CBCP (Callback Control Protocol) for callback. PPP 
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4. Satellite Controller Required Functions 


All satellite management controllers are required to implement the mandatory IPM Device commands. All other 
functions are optional. If a function is implemented, such as Event Generation or Sensors, then the mandatory 
commands for that function must be implemented. 


It is highly recommended that satellite controllers that provide sensors also provide event generation for those 


sensors. This will eliminate the need for system management software to poll to detect event conditions. It is also 
highly recommended that all satellite management controllers provide a Primary FRU Inventory device. 
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5. Message Interface Description 


The heart of this specification is the definition of the messages and data formats used for implementing sensors, 
event messages, Event Generators and Event Receivers, the SDR Repository, and the System Event Log in the 
platform management architecture. These messages are designed for delivery via a messaging interface with a 
particular set of characteristics. This section presents the general specification of that interface, and of the messages 
themselves. 


The Message Interface is defined as a ‘request/response’ interface. That is, a request message is used to initiate an 
action or set data, and a response message is returned to the Requester . In this document, Request Messages are 
often referred to as ‘commands’ or ‘requests’, and Response Messages as ‘responses’. 


All messages in this specification share the same common elements as the payload to the ‘command interpreter’ in 
the logical device that receives the message. The messaging interfaces differ in the framing, physical addressing, and 
data integrity mechanisms that are used to deliver this payload. 


The following are the common components of messages specified in this document: 


Network Function (NetFn) A field that identifies the functional class of the message. The Network 
Function clusters IPMI commands into different sets. See Section 5.1, 
Network Function Codes, for more information. 


Request/Response identifier A field that unambiguously differentiates Request Messages from 
Response Messages. In the IPMB Protocol, this identifier is ‘merged’ with 
the Network Function code such that ‘Even’ network function codes 
identify Request Messages, and ‘Odd’ network function codes identify 
Response Messages. 


Requester’s ID Information that identifies the source of the Request. This information 
must be sufficient to allow the Response to be returned to the correct 
Requester. For example, for the IPMB the Requester’s ID consists of the 
Slave Address and LUN of the Requester device. For a multiple stream 
system interface the Requester’s ID is the ‘stream id’ for the stream 
through which the request was issued. 


Responder’s ID A field that identifies the Responder to the Request. In Request Messages 
this field is used to address the Request to the desired Responder, in 
Response Messages this field is used to assist the Requester in matching 
up a response with a given request. 


Command The messages specified in this document contain a one-byte command 
field. Commands are unique within a given Network Function. Command 
values can range from 00h through FDh. Code FEh is reserved for future 
extension of the specification, and code FFh is reserved for message 
interface level error reporting on potential future interfaces. 


Data The Data field carries the additional parameters for a request or a response, 
if any. 


5.1 Network Function Codes 


The network layer in the connection header consists of a six-bit field identifying the function to be accessed. The 
remaining two bits are the LUN field. The LUN field provides further sub-addressing within the node. 


The network function is used to cluster commands into functional command sets. In a parsing hierarchy, the LUN 
field may be thought of as the selector for a particular Network Function handler in the node, and the Network 
Function may be considered the selector for a particular command set handler within the node. 
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The following table defines the supported network functions. With the exception of the Application and Firmware 
Transfer network functions, the commands and responses for a given network function are not node specific. The 
format and function for standard command sets is specified later in this specification. 


Table 5-, Network Function Codes 


Value(s) [Name [Meaning — [Description 


8 
E 
04, 05 Sensor 

/Event 


i 


8 


5 
i i 


OEh-2Bh 


Reserved 


Chassis 
Device 
Requests and 
Responses 
Bridge 
Requests and 
Responses 


Sensor and 
Event 
Requests and 
Responses 
Application 
Requests and 
Responses 


Firmware 
Transfer 
Requests and 
Responses 
Non-volatile 
storage 
Requests and 
Responses 
Media-specific 
configuration 
& control 


00h identifies the message as a command/request and 01h as a 
response, relating to the common chassis control and status functions. 


02h (request) or 03h (response) identifies the message as containing 
data for bridging to the next bus. This data is typically another 
message, which may also be a bridging message. This function is 
present only on bridge nodes. 

This functionality can be present on any node. 04h identifies the 
message as a command/request and 05h as a response, relating to 
the configuration and transmission of Event Messages and system 
Sensors. 

06h identifies the message as an application command/request and 
07h a response. The exact format of application messages is 
implementation-specific for a particular device, with the exception of 
App messages that are defined by the IPMI specifications. 


Note that it is possible that new versions of this specification will 
identify new App commands. To avoid possible conflicts with future 
versions of this specification, it is highly recommended that the 
OEM/Group network functions be used for providing ‘value added’ 
functions rather than the App network function code. 

The format of firmware transfer requests and responses matches the 
format of Application messages. The type and content of firmware 
transfer messages is defined by the particular device. 


This functionality can be present on any node that provides non- 
volatile storage and retrieval services. 


Requests (0Ch) and responses (0Dh) for IPMI-specified messages 
that are media-specific configuration and operation, such as 
configuration of serial and LAN interfaces. 


reserved (30 Network Functions [15 pairs]) 
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Group Non-IPMI The first data byte position in requests and responses under this 

Extension group network function identifies the defining body that specifies command 
Requests and | functionality. Software assumes that the command and completion 
Responses code field positions will hold command and completion code values. 


The following values are used to identify the defining body: 
00h** PICMG - PCI Industrial Computer Manufacturer's Group. 


(www.picmg.com) 
01h DMTF Pre-OS Working Group ASF Specification 


(www.dmtf.org) 

02h Server System Infrastructure (SSI) Forum 
(www.ssiforum.org) 

03h VITA Standards Organization (VSO) 
(www.vita.com) 

DCh DCMI Specifications 
(www.intel.com/go/dcmi) 

all other Reserved 


When this network function is used, the ID for the defining body 
occupies the first data byte in a request, and the second data byte 
(following the completion code) in a response. 
2Eh, 2Fh | OEM/Group OEM/Non- The first three data bytes of requests and responses under this 

IPMI group network function explicitly identify the OEM or non-IPMI group that 

Requests and | specifies the command functionality. While the OEM or non-IPMI group 

Response defines the functional semantics for the cmd and remaining data fields, 
the cmd field is required to hold the same value in requests and 
responses for a given operation in order to be supported under the 
IPMI message handling and transport mechanisms. 


When this network function is used, the IANA Enterprise Number for 
the defining body occupies the first three data bytes in a request, and 
the first three data bytes following the completion code position ina 
response. 
30h-3Fh Controller- Vendor specific (16 Network Functions [8 pairs]). The Manufacturer ID 
specific associated with the controller implementing the command identifies the 
OEM/Group vendor or group that specifies the command functionality. While the 
vendor defines the functional semantics for the cmd and data fields, 
the cmd field is required to hold the same value in requests and 
responses for a given operation in order for the messages to be 
supported under the IPMI message handling and transport 
mechanisms. 
Network Functions that are only utilized in systems that incorporate Bridge nodes. 
This organization value was named ‘Compact PCI’ in revision 1.0 of this document. 


* 


*k 


5.2 Completion Codes 


All Response Messages specified in this document include a completion code as the first byte in the data field of 
the response. A management controller that gets a request to an invalid (unimplemented) LUN must return an 
error completion code using that LUN as the responder’s LUN (RsLUN) in the response. The completion code 
indicates whether the associate Request Message completed successfully and normally, and if not, provides a 
value indicating the completion condition. 


Completion Codes work at the ‘command’ level. They are responses to the interpretation of the command after it 
has been received and validated through the messaging interface. Errors at the ‘network’ (messaging interface) 
level are handled with a different error reporting mechanism. For example the SMIC System Interface includes 
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status codes that are separate from the IPMI message data and used to report changes in communication phase or 
errors in the interface. 


Completion Code values are split into ‘generic’, ‘device-specific’ (which covers OEM) and ‘command-specific’ 
ranges. All commands can return Generic Completion Codes. Commands that complete successfully shall return 
the 00h, ‘Command Completed Normally’, Completion Code. Commands that produce error conditions, or return 
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a response that varies from what was specified by the Request parameters for the command, shall return a non- 
zero Completion Code, as specified in the following table. 


Table 5-, Completion Codes 
Definition 


GENERIC COMPLETION CODES 00h, COh-FFh 


Command Completed Normally. 


COh Node Busy. Command could not be processed because command processing 
resources are temporarily unavailable. 
Cih Invalid Command. Used to indicate an unrecognized or unsupported command. 


C2h Command invalid for given LUN. 


C3h 
space required to execute the given command operation. 

C5h 

C6h 

C7h 

C8h 


C9h Parameter out of range. One or more parameters in the data field of the 
Request are out of range. This is different from ‘Invalid data field’ (CCh) code in 
that it indicates that the erroneous field(s) has a contiguous range of possible 
values. 


CAh Cannot return number of requested data bytes 


CBh 
CCh 
CDh 
CEh 


CFh Cannot execute duplicated request. This completion code is for devices which 
cannot return the response that was returned for the original instance of the 
request. Such devices should provide separate commands that allow the 
completion status of the original request to be determined. An Event Receiver 
does not use this completion code, but returns the 00h completion code in the 
response to (valid) duplicated requests. 


DOh Command response could not be provided. SDR Repository in update mode. 
Dih Command response could not be provided. Device in firmware update mode. 


D2h Command response could not be provided. BMC initialization or initialization 
agent in progress. 

D3h Destination unavailable. Cannot deliver request to selected destination. E.g. this 
code can be returned if a request message is targeted to SMS, but receive 
message queue reception is disabled for the particular channel. 

D4h Cannot execute command due to insufficient privilege level or other security- 
based restriction (e.g. disabled for ‘firmware firewall’). 

D5h Cannot execute command. Command, or request parameter(s), not supported 

in present state. 

D6h Cannot execute command. Parameter is illegal because command sub-function 
has been disabled or is unavailable (e.g. disabled for ‘firmware firewall’). 

FFh Unspecified error. 

DEVICE-SPECIFIC (OEM) CODES 01h-7Eh 


O1h-7Eh | Device specific (OEM) completion codes. This range is used for command- 
specific codes that are also specific for a particular device and version. A-priori 
knowledge of the device command set is required for interpretation of these 
codes. 

COMMAND-SPECIFIC CODES 80h-BEh 


80h-BEh | Standard command-specific codes. This range is reserved for command- 
specific completion codes for commands specified in this document. 


all other | reserved 
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5.3 Completion Code Requirements 


Completion Codes are provided as an aid in system debugging and error handling. All devices meeting the 
command specifications of this document shall implement the 00h, ‘Command Completed Normally’ for the 
commands specified in this document. 


It is mandatory that devices that produce error conditions, or return a response that varies from what was specified 
by the Request parameters for the command, return a non-zero Completion Code from the preceding table. 


In some cases, it is required that a particular completion code be returned for a specified condition. This typically 
occurs with command-specific completion codes. These cases are documented in the sections describing the 
particular command or function. 


Otherwise, if a device implementation produces a completion condition that matches a Generic or Command- 
specific completion code for the command, the device shall either return that specific value, or the ‘unspecified 
error’ Completion Code, FFh. It is highly desirable that device implementations return an explicit completion 
code, rather than “unspecified error’, whenever feasible. 


In the case that multiple ‘non-zero’ completion conditions occur simultaneously, the implementation should return 
whichever completion code the implementer deems to best indicate the condition that the Requester should correct 
or handle first. 


New for IPMI 1.5 Controllers and software that handle IPMI commands: The value Clh (Invalid Command) 
must be returned for unsupported commands, except when the controller or software is in a mode where general 
command handling is unavailable. For example, if the controller is in a firmware update mode, it is legal to return 
Dih (Command response could not be provided, device in firmware update mode) instead of C1h. 


New for IPMI v2.0 Controllers and software that handle IPMI commands: The D4h completion code has been 
extended to indicate that an insufficient privilege level or command restriction due to Firmware Firewall was the 
reason a command could not be accessed. Similarly, a D6h completion code has been added to indicate that a 
particular sub-function could not accessed due to Firmware Firewall. 


5.3.1 Response Field Truncation on non-zero Generic Completion Codes 


The responder may, as an implementation option, truncate data bytes following a non-zero completion code 
field and any IPMI-specified addressing extension bytes, such as the Group Extension code for NetFn 2Ch/2Dh 
or the IANA for NetFn 2Eh/2Fh. Typically, a responder will truncate all fields following a non-zero completion 
code and addressing extension bytes. If additional fields are returned, however, they should be assumed to have 
device-specific content unless otherwise specified. 


5.3.2 Summary of Completion Code Use 
The following is a summary list of the completion code rules and guidelines. 
e A 00h Completion Code must be returned with a normal response to a standard command. 


e It is recommended that a 00h Completion Code also be returned for the normal responses to OEM 
commands. 


e A non-zero Completion Code must be returned for an error or atypical response to a standard command. 


e It is recommended that a non-zero Completion Code be returned for an error or atypical response to an 
OEM command. 
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e The value C1h (Invalid Command) must be returned for unsupported commands, except when in a mode 
where general command handling is unavailable. 


e Ifthe specification calls out that a particular completion code must be returned for a given condition, that 
code must be returned. 


e Otherwise, it is recommended that an implementation return the closest generic completion code for an 
error condition. If an implementation is resource constrained or the error classification is ambiguous, the 
FFh (unspecified error) completion code can be returned. 


e Device-specific (OEM) completion codes should only be returned when a suitable generic completion code 
is unavailable. Generic software will treat device-specific completion codes as if they were FFh 
(unspecified error) completion codes. 


e Except for mandatory completion codes, software must not depend on a particular non-zero completion 
code to be returned for a given error condition, since it is possible that an FFh or device-specific code could 
be returned instead. 


e Itis illegal to return a generic or command-specific completion code for a condition that doesn’t exist, 
unless it is being used as part of emulating a device or interface. For example, an implementation might 
enable the Master Write-Read command to be used to access a Private Management Bus interface that is 
not physically an DC bus. The implementation is allowed to return completion codes related to DC bus 
status as part of the emulation. 


5.4 Sensor Owner Identification 


The definition for the Request/Response identifier, Requester’s ID, and Responder’s ID are specific to the 
particular messaging interface that is used. However, the Sensor Data Record and SEL information must contain 
information to identify the ‘owner’ of the sensor. For management controllers, a Slave Address and LUN identify 
the owner of a sensor on the IPMB. For system software, a Software ID identifies the owner of a sensor. These 
fields are used in Event Messages, where events from management controllers or the IPMB are identified by an 
eight-bit field where the upper 7-bits are the Slave Address or System Software ID. The least significant bit is a 0 
if the value represents a Slave Address and a | if the value represents a System Software ID. 


The Sensor Number is not part of the Sensor Owner ID, but is a separate field used to identify a particular sensor 
associated with the Sensor Owner. The combination of Sensor Owner ID and Sensor Number uniquely identify a 
sensor in the system. 


Table 5-, Sensor Owner ID and Sensor Number Field Definitions 
System Sensor Owner ID 


7:1 Slave Address (7-bits) 7:1 System Software ID (7-bits) 
0 0b (ID is a slave address) 0 1b (ID is a Software ID) 


See Table 5-4, System Software IDs, 
below. 


LUN (2-bits) Sensor Number (8 bits, FFh = reserved) 
Sensor Number (8-bits, FFh = reserved) 


5.5 Software IDs (SWIDs) 


The following table presents a list of the Sensor Owner IDs for ‘system software’ sensor owners or IPMI message 
generators. These values are used when system software issues Event Messages via the system interface, and 
when remote console software sends messages to the BMC. For example, if BIOS detects a processor failure, it 
can generate an Event Message to get the failure event logged. When it formats the Event Message, the BIOS 
‘System Owner ID’ is included in the Event Message. Later, System Management Software can access the System 
Event Log and tell that the Event Message was generated by BIOS. 
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For IPMB Messages, the Sensor Owner ID is assumed to be the same as the device that originated the message. 
Therefore, the Slave Address and LUN of the Event Generator are used. For system-side sensors, it is assumed 
that the class of software that generates the sensor commands is the ‘owner’ of the sensor. 


Table 5-, System Software IDs 


| System Software Type | IDs (7-bit) | bito' | Resultant 8-bit value! | 


[reserved remaining [16 | 


1. The System Software ID is often used in an 8-bit field where the least-significant 
bit is a 1b to indicate that the field holds a Software ID rather than a slave 
address. One example of this occurs in the first byte of the Generator ID field in 
an event message. The last column in the above table illustrates how the 7-bit 
Software ID appears in such a 1-byte field. 


5.6 Isolation from Message Content 


The SEL, SDR, and Event commands are designed so that the ‘devices’ that implement those command sets are 
generally isolated from the content of the SEL Entry, Sensor Data Record, and Event Message contents. That is, 
the Event Receiver device receives and routes Event Messages, but does not interpret them. Similarly, the SEL 
and SDR devices retrieve and store log entries and Sensor Data Records, respectively, without interpreting their 
contents. 
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6. IPMI Messaging Interfaces 


This section introduces the common characteristics of the messaging interfaces to the BMC and between the BMC 
and system software. As mentioned earlier, there are three System Interface implementations specified for the BMC: 
SMIC, KCS, and BT. The BMC can also be communicated with through additional interfaces such as the IPMB, 
ICMB, LAN, and Serial/Modem interfaces. Information specific to the operation and usage of a particular interface 
is given in later sections. 


6.1 Terminology 


The ICMB, LAN, and Serial/Modem interfaces are typically used to communicate with management software on 
another system. The remote software that is used to communicate with the BMC is referred to as the remote console. 
Although the word ‘console’ is used, the remote software may or may not provide a user interface or require user 
interaction. 


Local software running on the managed system and using the System Interface to the BMC will generally be 
referred to as system management software or SMS. Unless otherwise indicated, the direction of communications is 
given with respect to the BMC. E.g. transmitted, outbound, or outgoing messages are issued from the BMC. 
Received, inbound, or incoming messages are accepted by the BMC. Other terminology used for IPMI Messaging 
will be introduced as it is used in the following sections. 


6.2 Channel Model 


IPMI uses a ‘channel model’ for directing communication between different interfaces in the BMC. Channels serve 
as the means for identifying the medium for a messaging interface, and for configuring user information and 
passwords, message authentication, access modes and privilege limits associated with that interface. 


Each channel has its own set of configuration parameters for user information and channel privilege limits. This 
allows different sets of user names and passwords and different levels and types of authentication to be used on 
different channels. IPMI Messaging and Alerting can also be independently enabled or disabled for an entire channel 
on a per channel basis. 


Channels share commands related to authentication, access, and configuration. These commands are independent 
from the type of communication medium. This reduces the amount of medium-specific information that software 
needs to deal with, and simplifies task such as bridging IPMI messages between different media. 


6.3 Channel Numbers 
Each interface has a channel number that is used when configuring the channel and for routing messages between 


channels. Only the channel number assignments for the primary IPMB and the System Interface are fixed, the 
assignment of other channel numbers can vary on a per-platform basis. Software uses a Get Channel Info command 
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to determine what types of channels are available and what channel number assignments are used on a given 
platform. The following table describes the assignment and use of the channel numbers: 


Table 6-, Channel Number Assignments 


Channel 
Number | Type/Protocol Description 


0 Primary IPMB Channel 0 is assigned for communication with the primary IPMB. 
IPMB protocols are used for IPMI messages. Refer to [IPMB] for 
more information. 
1-Bh Implementation- Channels 1-7 can be assigned to different types types of 
specific communication media and protocols for IPMI messages (e.g. IPMB, 
LAN, ICMB, etc.), based on the system implementation. For IPMI 
1.5, ‘Channel Protocol Type’ and ‘Channel Medium Type’ numbers 
identify the channel’s protocol and medium, respectively. Software 
can use the Get Channel Info command to retrieve this information. 
Ch-Dh - Reserved 

Eh Present I/F The value Eh is used as a way to identify the current channel that 
the command is being received from. For example, if software 
wants to know what channel number it’s presently communicating 
over, it can find out by issuing a Get Channel Info command for 
channel E. 
Fh System Interface Channel ‘F’ is assigned for routing messages to the system 
interface. 


6.4 Channel Protocol Type 


The protocol used for transferring IPMI messages on a given channel is identified using a channel protocol type 
number. In earlier versions of the specification, this also implied the particular medium for the channel. The 
Channel Medium Type number is now used to explicitly indicate the class of the media. Both these values are 
used in the Get Channel Info command. 


Sensor Data Record 14h - BMC Message Channel Info is superceded by the Get Channel Info command. New 
implementations should use the Get Channel Info command instead. 


Table 6-, Channel Protocol Type Numbers 


Channel 
Protocol 
(5-bits) Name Description 
00h n/a reserved 
01h IPMB-1.0 Used for IPMB, serial/modem Basic Mode, and LAN 
02h ICMB-1.0 ICMB v1.0 - See Section 8, ICMB Interface. 
03h reserved reserved 
04h IPMI-SMBus | IPMI on PCI-SMBus / SMBus 1.x - 2.x I] 
Request = [rsSA, Netfn(even)/rsLUN, 00h, raSA, rqSeg/rgLUN, CMD), <data>, 
PEC] 
Response = [rqSA or rqSWID, NetFn(odd)/rqLUN, 00h, rsSA or rsSWID, 
rqSeq/rsLUN, CMD, completion code, <data>, PEC] 
05h KCS KCS System Interface Format - See Section 9, Keyboard Controller Style (KCS) 
Interface 
06h SMIC SMIC System Interface Format - See Section 10, SMIC Interface 
07h BT-10 BT System Interface Format, IPMI v1.0 - See Section 11, Block Transfer (BT) 
Interface 
08h BT-15 BT System Interface Format, IPMI v1.5 - See Section 11, Block Transfer (BT) 
Interface 
09h TMode Terminal Mode - See Section 14.7, Terminal Mode 
1Ch-1Fh n/a OEM Protocol 1 through 4, respectively 
all other reserved 
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1. Note that the IPMI format is intentionally illegal with respect to the SMBus specification protocols in order to provide a way 
for a management controller to unambiguously differentiate IPMI messages from SMBus transactions. This enables a 
management controller to support both SMBus and IPMI protocols without concern that they would overlap. The PEC 
(packet error code) is an 8-bit CRC calculated per the SMBus 2.0 specification. This format makes it simple to use the 
same hardware or firmware routines for data integrity checking of both IPMI and SMBus messages.) 

2. Note that certain network functions, such as OEM/Group, require additional standard fields within the <data> portion of a 
message. 


6.5 Channel Medium Type 


The Channel Medium Type number is a seven-bit value that identifies the general class of medium that is being 
used for the channel. 


Table 6-, Channel Medium Type Numbers 


Channel 
Type Description 
0 reserved 
1 IPMB (I2C) 
2 ICMB v1.0 
3 ICMB v0.9 
4 802.3 LAN 
5 Asynch. Serial/Modem (RS-232) 
6 Other LAN 
7 PCI SMBus 
8 SMBus v1.0/1.1 
9 SMBus v2.0 
Ah reserved for USB 1.x 
Bh reserved for USB 2.x 
Ch System Interface (KCS, SMIC, or BT) 
60h-7Fh | OEM 
all other | reserved 


6.6 Channel Access Modes 


Session-based channels can be configured to provide IPMI Messaging access only when the system is in certain 
states. This allows the system user to configure various levels of security and remotely accessible features. The 
access modes are summarized in the Table 6-, Channel Access Modes. Commands allow the power-up default 
(non-volatile) Access Mode for a channel to be configured, and allow the Access Mode setting to be changed 
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dynamically. Channel Access Modes are configured using the Set Channel Access command. The Set Channel 
Access command is also used to enable or disable Alerting for the entire channel. 


Support for any given access mode is implementation specific. It is expected that most implementations will 
support Disabled and Always Available, and that serial/modem channels will also support the Shared access 
mode. 


Table 6-, Channel Access Modes 


Pre-boot The channel is only available out-of-band while the machine is powered-off and during POST until the 
Only boot process is initiated. This option is primarily used with Serial Port Sharing where it may be desirable 
to ensure that the BMC does not take control of the serial port during OS run-time. The BMC will not 
claim the port once the port has been switched over to the system using the ‘force mux’ option in the Set 
Serial/Modem Mux command, unless the system becomes powered down or is reset. 


As a consequence, run-time software must rely on mechanisms such as the IPMI Watchdog Timer to 
power down or reset the system in order to enable communication to the BMC under failure conditions. 


There is a Modem Ring Time parameter in the serial/modem channels that configures the amount of time 
that the BMC waits for RING before directing the modem to connect. This parameter can be used to 
enable the BIOS to ‘answer the phone’ instead of the BMC. See Table 14-, Serial Port Sharing Access 
Characteristics for more information. 


LAN Channels do not typically allow setting Pre-boot Access Mode. If it is provided, BIOS should disable 
the channel at the end of POST (start of boot) by using the Set Channel Access command to set the 
channel to ‘disabled’ using the volatile setting. 

The Pre-boot Only setting does not affect serial/modem alerting. If alerting is enabled and software does 
not handle the event, the BMC will take control of the port/channel for the time it takes to deliver the alert. 
Alerting can be enabled or disabled for an entire channel via the Set Channel Access command. 

Always The channel is dedicated to communication with the BMC and is available during all system states 
Available (powered-down, powered-up, pre-boot, sleep, run-time, etc.) For IPMI LAN channels, this means that 
RMCP packets are handled by the BMC. 


For serial/modem channels on systems that support serial port sharing, the port can still be switched 
over to the system, however the BMC will always ‘answer the phone’ and respond to escape sequences 
and packets that activate the port. The BIOS will typically disable software access to the serial port when 
it sees the BMC configured for Always Available mode. This is done to prevent any possible confusion 
between auto-answer applications running on the OS and the BMC’s answering of the phone. 


Shared The channel can be shared between system software and the BMC. 


Shared Mode is typically only used when there is a need to switch the communication resource between 
system software and the BMC because the system and BMC cannot readily interleave their traffic on the 
medium, as is the case with Serial Port Sharing. 


For IPMI LAN Channels, Shared Mode means that the implementation allows system software to receive 
and respond to RMCP packets. However, this does not prevent the BMC from handling IPMI RMCP 
packets and RMCP Ping/Pong. If software wanted exclusive access to RMCP Packets, it would need to 
temporarily disable IPMI messaging by setting the volatile setting of the access mode to ‘disabled’. Note 
that if system software failed, a system reset (e.g. watchdog reset) or power down would be required to 
restore LAN communication with the BMC. 


For serial/modem channels that support Serial Port Sharing, the system BIOS will typically leave the 
baseboard serial port available for software use when it sees this mode set. This allows system software 
to use the port and any external modem for ‘outgoing’ traffic, while the BMC can still ‘answer the phone’ 
for incoming calls. Thus, in shared mode, the mux will be set to ‘system’ whenever the BMC is not in the 
process of answering a call or handling or establishing an IPMI messaging session. 


There is a Modem Ring Time parameter in the serial/modem channels that configures the amount of time 
that the BMC waits for RING before directing the modem to connect. This parameter can be used to 
enable ‘auto answer’ OS applications, while providing a way to connect to the BMC if a failure prevents 
the run-time application from answering the phone. 


If the Modem Ring Time is set to a non-zero wait time, the BMC will leave the mux set to the system until 
the Modem Ring Time expires, at which time the BMC can answer the phone. If the Modem Ring Time is 
set to a zero wait time, the BMC will take the mux and attempt to answer the phone as soon as it detects 
an incoming call. See Table 14-, Serial Port Sharing Access Characteristics for more information. 
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Disabled The channel is disabled from being used to communicate with the BMC. The Disabled setting does not 
affect alerting. Alerting is separately enabled or disabled via a separate field in the Set Channel Access 
command. 


6.7 Logical Channels 


From the IPMI Messaging point-of-view, a party that bridges a message from one channel to another only is 
mainly concerned that it gets the correct response from the BMC. Often, it doesn’t matter to remote console or 
system software whether the target channel and devices are physically implemented or not. For example, a BMC 
could implement a logical IPMB where the BMC would respond to messaging commands as if there was a 
physical IPMB with other management controllers on it. An implementation might elect to do this for several 
reasons. One reason would be that the board vendor wanted to use an alternative bus for interconnecting the 
management functions within their board set. Another possibility is that a logical IPMB could provide a way to 
organize add-on functions to the BMC, such as embedding a logical ICMB Bridge controller. 


6.8 Channel Privilege Levels 


Channel privilege limits determine the maximum privilege that a user can have on a given channel. One channel 
can be configured to allow users to have up to Administrator level privilege, while another channel may be 
restricted to allow no higher than User level. The privilege level limits take precedence over the privilege level 
capabilities assigned per user. 


Channels can be configured to operate with a particular maximum Privilege Level. Privilege levels tell the BMC 
which commands are allowed to be executed via the channel. Table 6-, Channel Privilege Levels, lists the 
currently defined privilege levels. The Set Channel Access command is used to set the maximum privilege level 
limit for a channel. The Set Session Privilege Level Command is used to request the ability to perform operations 
at a particular privilege level. The Set Session Privilege Level command can only be used to set privilege levels 
that are less than or equal to the privilege level limit for the entire channel, regardless of the privilege level of the 


user. 


Table 6-, Channel Privilege Levels 


Callback 


This may be considered the lowest privilege level. Only commands necessary to support initiating a Callback are 
allowed. 

Appendix G - Command Assignments, provides a list of the commands that are executable when operating at 
Callback Level. 


User 


Only ‘benign’ commands are allowed. These are primarily commands that read data structures and retrieve 
status. Commands that can be used to alter BMC configuration, write data to the BMC or other management 
controllers, or perform system actions such as resets, power on/off, and watchdog activation are disallowed. 
Appendix G - Command Assignments, provides a list of the commands that require operating at User level or 
higher. 


Operator 


All BMC commands are allowed, except for configuration commands that can change the behavior of the out-of- 
band interfaces. For example, Operator privilege does not allow the capability to disable individual channels, or 
change user access privileges. 

Appendix G - Command Assignments, provides a list of the commands that require operating at Operator level or 
higher. 


Administrator 


All BMC commands are allowed, including configuration commands. An Adminstrator can even execute 
configuration commands that would disable the channel that the Administrator is communicating over. 
Appendix G - Command Assignments, provides a list of the commands that require operating at Administrator 
level. 


6.9 Users & Password Support 


The term user is used in this specification to refer to a collection of data that identifies a password (key) for 
establishing an authenticated session, and the privileges associated with that password. For configuration 
purposes, the sets of user information are organized and accessed according to a numeric User ID. When 
activating a session, user information is looked up using a text username. 
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User access can be enabled on a per channel basis. Thus, different channels can have different sets of users 
enabled. 


If desired, a username on one channel can be associated with a different password than the same username on a 
different channel. When a session is activated, the BMC will scan the usernames sequentially starting with 
User ID 1 and will look for the first user that has a matching username and has access enabled for the given 
channel. Thus, having different passwords for a given username requires configuring multiple user entries - one 
for each different password that is to be used for a particular set of channels. 


The specification allows a number of different implementations for supporting users on a channel. The following 
lists the minimum requirements: 


All authenticated channels are required to support at least one user (User ID 1). 
Usernames may be fixed or configurable, or a combination of both, at the choice of the implementation. 


If an implementation supports only one user with a fixed user name, then the fixed user name must be null 
(all zeros). 


Support for configuring user passwords for all User IDs is required. 


Support for setting per-user privilege limits is optional. If the Set User Access command is not supported, the 
privilege limits for the channel are used for all users. 


6.9.1 ‘Anonymous Login’ Convention 


The IPMI convention for enabling an ‘anonymous’ login is to configure the entry for User ID 1 with a null 
username (all zero’s) and a null password (all zero’s). Applications may then present this to the user as an 
anonymous login and configuration option, knowing what username and password to use if the BMC allows 
‘anonymous’ logins. The reason for doing this via User ID 1 is to simplify the task of enabling the BMC to 
report whether anonymous login is enabled or not. 


6.9.2 Anonymous Login Status 


The Get Channel Authentication Capabilities command includes a ‘Anonymous Login Status’ field. This field 
indicates to a remote console application whether User ID I is presently configured with a null username and 
null password. In addition, a bit is provided that indicates whether there are also non-null usernames enabled for 
the channel, or whether User ID 1 holds a null username, but a non-null password. 


Together, these bits can be used to guide a remote application in presenting connection options to a user. For 
example, if a system only has Anonymous Login enabled, the application could immediately connect without 
prompting the user, or use that information to enable an ‘anonymous login’ button in the user interface. If a 
system has a null username but non-null password, the application could put up just a password dialog box. 
Lastly, if the system indicates it has non-null usernames with non-null passwords, the application may put up a 
dialog box prompting for both a user name and password. 


6.10 System Interface Messaging 


The following sections describe how messaging works across the system interface to the BMC. Later sections go 
into detail on message formats and register interfaces for the different physical implementation options for the 
system interface. 


6.10.1 BMC Channels and Receive Message Queue 


Messaging between system software and the other management busses, such as the IPMB, is accomplished 
using channels and a Receive Message Queue. A channel is a path through the BMC that allows messages to be 
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sent between the system interface and a given bus or message transport. The Receive Message Queue is used to 
hold message data for system software until system software can collect it. All channels share the Receive 
Message Queue for transferring messages to system management software. The Receive Message Queue data 
contains channel, session, and IPMI addressing information that allows system software to identify the source 
of the message, and to format a message back to the source if necessary. 


System management software is responsible for emptying the Receive Message Queue whenever it has data in 
it. Messages are rejected if the Receive Message Queue gets full. It is recommended that the Receive Message 
Queue have at least two ‘slots’ for each channel. The Receive Message Queue is a logical concept. An 
implementation may choose to implement it as an actual queue, or could implement separate internal buffers for 
each channel. It is recommended that the implementation attempt to leave a slot open for each channel that does 
not presently have a message in the queue. This helps prevent ‘lock out’ by having the queue fill with just 
messages from one interface. 


The BMC itself can, if necessary, use the Receive Message Queue and Messaging Channels to send 
asynchronous messages to system management software. The recommended mechanism for accomplishing this 
is to define a unique channel with a protocol type of ‘System’. To send an asynchronous message to system 
software, the BMC would place a message from that channel directly into the Receive Message Queue in 
‘System’ format. System software would be able to respond back to the BMC using a Send Message command 
for that channel. 


6.10.2 Event Message Buffer 


[Optional] - The Event Message Buffer holds Event Request Messages that have been internally generated by 
the BMC, and Event Messages that have been received by the BMC from the IPMB or other channel. The Event 
Message Buffer does not hold event messages that have been generated from system software. 


The Event Message Buffer holds all 16-bytes of the Event Message as it would be stored in the System Event 
Log (see Table 26-1, SEL Event Records). For IPMI v1.5, the Event Message Buffer does not get overwritten if 
a new event comes in before system software can empty the buffer. The BMC does clear the buffer when the 
BMC is first powered up and whenever the system becomes powered up or is hard reset. A BMC 
implementation can support generating a system interrupt when the Event Message Buffer gets filled. 


Some implementations will elect to generate an SMI to allow the creation of an SMI Handler that takes 
additional actions on Event Messages. If Event Message Buffer interrupts do not generate SMI, or are not 
enabled (or not implemented), SMS can use this as a mechanism for examining Event Messages as they are 
received. System software must check the status of SMI use before assuming that the Event Message resource is 
available. This can be accomplished by using the Get Channel Info command to determine if the interrupt 
assignment for the Event Message Buffer is set to SMI. 


Note: SMM Messaging and the implementation of SMIs is OPTIONAL. Since SMI operation and functions 
are proprietary and not described nor required in this specification, support via the IPMI interfaces is 
being deprecated. New implementations should avoid using the IPMI support for SMI. 


6.11 System Interface Discovery and Multiple Interfaces 


A BMC device may make available multiple system interfaces, but only one management controller is allowed to 
be the ‘active’ BMC that provides BMC functionality for the system (in the case of a ‘partitioned’ system, there 
can only one active BMC per partition). Only the system interface(s) for the active BMC are allowed to respond 
to the Get Device ID command. If other BMC devices are present, but not being used, they must not respond to 
the Get Device ID command. 


When system interfaces are available, the driver can select the type interface it wishes to use. 


54 


Intelligent Platform Management Interface Specification 


Drivers should not switch system interfaces during system operation or else unexpected results could occur. The 
Get Device ID command is required to execute correctly across multiple interfaces to a BMC, but other 
commands are not. Once the driver has chosen to use a given interface, all commands beyond Get Device ID 
should be delivered to that interface. If it is desired to change the choice of system interfaces, a warm or cold reset 
of the platform should be done to ensure that the system can re-initialize BMC operation. 


It is recommended that run-time drivers support the IPMI System Interfaces in the following order: 


e A driver should preferentially use the BMC on PCI, via the OS’s native support, if available. (A “Plug and 
Play” OS will typically locate and load the appropriate driver for devices it finds on PCI.) Appendix C2 - 
Locating IPMI System Interfaces on PCI, summarizes the PCI Class codes for IPMI System Interfaces. 


e If the desired interface is not available on PCI, or the system is in a state where OS support for PCI is 
unavailable the next step should be to look for the system interface as a static resource described in ACPI 
using the control methods described in Appendix C3, Locating IPMI System Interfaces with ACPI. 


e Ifthe operating environment does not include a mechanism to support executing ACPI control methods, 
then look for the system interface at the location described by the SPMI (Service Processor Management 
Interface) Table(s) through the ACPI Description Table mechanisms. (The SPMI Table approach supports 
BMCs that offer more than one system interface. Therefore, there can be more than one instance of the 
SPMI Table.) The SPMI Table is described in Appendix C2 - Locating IPMI System Interfaces on PCI. 


e Ifthe SPMI Table is not present, the driver should look for the SMBIOS Type 38 table (See Appendix C1 - 
Locating IPMI System Interfaces via SM BIOS Tables) and use the interface described there. Unlike the 
SPMI Table, there is only one instance of the Type 38 record allowed, so the driver will not need to look 
for additional interfaces. 


e Lastly, the driver should look for the IPMI System Interface at the fixed, default I/O addresses specified for 
the SMIC, KCS, and BT interfaces. Refer to the individual sections on those interfaces for the addresses. 


6.12 IPMI Sessions 


Authenticated IPMI communication to the BMC is accomplished by establishing a session. Once established, a 
session is identified by a Session ID. The Session ID may be thought of as a handle that identifies a connection 
between a given remote user and the BMC, using either the LAN or Serial/Modem connection. 


The specification supports having multiple active sessions established with the BMC. It is recommended that a 
BMC implementation support at least four simultaneous sessions. This number is shared between the LAN and 
Serial/Modem interfaces. 


The specification also allows a given endpoint (identified by an IP address) on the LAN to open more than one 
session to a BMC. The capability is allowed to allow a single system to serve as a proxy to provide BMC LAN 
sessions for other systems. It is not intended for one system to use this provision to open multiple sessions to the 
BMC for that system’s sole use. 


An IPMI messaging connection to the BMC fits one of three classifications, session-less, single-session, or multi- 
session. 


6.12.1 Session-less Connections 


A session-less connection is unauthenticated. There is no ‘user login’ required for performing IPMI messaging. 
The System Interface and IPMB are examples of session-less connections. 


A special case of a session-less connection can occur over an interface that supports session-based messaging. 
Session-based connections have certain commands that are accepted and responded to “outside of a session”. 
When that occurs, the channel is effectively operating in a session-less manner for those commands. Commands 
that are handled outside of a session have fixed values for session-specific fields in the message. For example, 
when the “Get Channel Authentication Capabilities” is sent over a LAN channel outside of a session, it is sent 
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with the Session ID set to NULL and authentication type set to NONE in the IPMI session header of the 
message. Note that commands that are accepted “outside of a session” can also be accepted within the context 
of a session, in which case they must have valid Session IDs, etc., in the session header in order to be accepted. 


6.12.2 Single-session Connections 


A single-session connection has a user authentication phase that precedes IPMI messaging. This is 
accomplished using the Get Session Challenge and Activate Session commands. A single-session connection is 
intended for a physically secure link. Therefore, individual packets are not signed. The serial/modem Basic 
Mode is an example of a single-session connection. 


6.12.3 Multi-session Connections 


A multi-session connection has user authentication and supports multiple interleaved sessions (multiple users). 
The multi-session connection is specified to support communication on a shared medium, such as LAN, where 
there may be a mix of IPMI and non-IPMI traffic. In order to support multiple sessions, and protect against 
attempts to circumvent authentication (such as replay attacks), multi-session packets have a session header in 
addition to the IPMI message. The session header carries information to identify the particular session, as well 
as Other fields such as session sequence numbers and authentication type fields. The LAN and PPP Mode 
connections are examples of multi-session IPMI messaging connections. 


6.12.4 Per-Message and User Level Authentication Disables 
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Typically, each packet in a multi-session connection is authenticated (with the exception of the packets for 
certain ‘pre-session’ commands such as Get Channel Authentication Capabilities, and Get Session Challenge.) 
In some cases however, the connection medium is considered to be trusted even though multiple user sessions 
are allowed. Once a session has been activated, the computational overhead of authenticating each packet may 
not be necessary. 


Thus, there are two options to enable performance improvements in environments where the link is considered 
to be secure. The options are to disable ‘Per-Message Authentication’, and to disable ‘User Level 
Authentication’. If Per-Message Authentication is disabled, the only packets that are required to be 
authenticated are the ones for the Activate Session request and response. Once the session is activated, the 
remaining packets will be accepted with the Authentication Type set to NONE. Since the Authentication Code 
(signature) is not provided in the packet when the Authentication Type is NONE, this enables a performance 
improvement in two ways: fewer bytes are transmitted, and the authentication algorithm doesn’t need to be run. 


In many cases, there is little concern about whether User Level commands are authenticated, since the User 
privilege allows status to be retrieved, but cannot be used to cause actions such as platform resets, or change 
platform configuration. Thus, an option is provided to disable authentication just for User Level commands. If 
User Level Authentication is disabled, then User Level messages will be accepted that have the Authentication 
Type set to NONE. 


The BMC will always verify any authenticated packets (Authentication Type not NONE) that it receives, 
regardless of whether Per-Message Authentication and/or User Level Authentication is disabled. Authenticated 
packets will be silently discarded if the signature (AuthCode) is invalid, or the Authentication Type does not 
match the authentication type that was negotiated when the session was activated. This is necessary to allow 
remote console software to deliver authenticated messages to the Receive Message Queue via the Send Message 
command. 


Both the Per-Message Authentication and User Level Authentication disable options are configured via the Set 
Channel Access command. 
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6.12.5 Link Authentication 


Sometimes connections offer authentication protocols that are applied as part of establishing the communication 
link to the BMC. For example, PPP supports authentication protocols such as PAP and CHAP that are part of 
link establishment. 


Link Authentication is a global characteristic associated with the connection mode for the channel. Link 
Authentication is enabled/disabled via the serial/nodem configuration parameters. When Link Authentication 
is enabled, it is necessary to identify one or more users that will serve as the source of the username (peer ID) 
and password information for the link. This is accomplished by setting an ‘Enable User for Link 
Authentication’ bit in the Set Channel Access command. 


For physically secure connections, these ‘Link Authentication’ protocols may be all that’s considered needed to 
authenticate the user. Thus, the BMC supports enabling Link Authentication for PPP using common PPP 
authentication algorithms. If Link Authentication is enabled, the Per-Message Authentication Disable, and User 
Level Authentication Disable options may be used to improve performance. 


6.12.6 Summary of Connection Characteristics 


The following table summarizes the key characteristics that differentiate session-less, single-session, and multi- 
session connections: 


Table 6-, Session-less , Single-session and Multi-session Characteristics 
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1. Terminal mode only supports ‘straight password’ authentication 
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6.12.7 IPMI v1.5 Session Activation and IPMI Challenge-Response 
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This section provides an overview of how sessions are activated in IPMI v1.5. (IPMI v2.0 adds using RMCP+ 
Authenticated Key-Exchange Protocol (RAKP), as the session establishment mechanism. See 13.3, RMCP+, 
and 13.15, IPMI v2.0/RMCP+ Session Activation). 


A session must be activated before general IPMI messaging can occur. For IPMI v1.5, the basic mechanism for 
accomplishing this is via a set of IPMI commands that are used to perform an “IPMI Challenge-Response”. This 
process involves three IPMI commands: Get Channel Authentication Capabilities, Get Session Challenge, and 
Activate Session. Of these three commands, the Get Channel Authentication Capabilities and Get Session 
Challenge command must be executable before the session is set up. Therefore, these commands can be thought 
of as always being ‘unauthenticated’. The Activate Session command is the first, and in some cases only, 
authenticated command for a session. Refer to Sections 13.3, RMCP+, and 13.14, IPMI v1.5 LAN Session 
Activation for more information on session establishment for LAN channels. 


Figure 6-, Session Activation 
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Referring to Figure 6-1, Session Activation, the following presents the general steps for activating a session: 
1. The Remote Console issues a Get Channel Authentication Capabilities request to the BMC. 


2. The BMC returns a Get Channel Authentication Capabilities response that contains which 
authentication types (authentication algorithms) it supports. 


3. The Remote Console sends a Get Session Challenge request to the BMC. The command selects which 
of the BMC-supported authentication types the Remote Console would like to use, and a username that 
selects which set of user information should be used for the session. This is the only place where the 
username is used during the process. 


4. The BMC looks up the user information associated with the username. If the user is found and allowed 
access via the given channel, the BMC returns a Get Session Challenge response that includes a 
randomly generated Challenge String and a temporary Session ID. The BMC keeps track of the 
username associated with the Session ID so that it can use the Session ID to look up the user’s 
information in the next step. In some algorithms, the BMC will store challenge string, or a seed that 
was used to generate the challenge, for later lookup as well. 
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5. The Remote Console then issues an Activate Session request. The request contains the temporary 
Session ID plus the authentication information based on the type of authentication that was selected. 
For example, a LAN packet would typically include a signature using an authentication algorithm run 
on elements such as the challenge string, user password/key, IPMI message fields, Session ID, etc. 
while a serial/modem connection may only pass a simple clear-text password in the activate session 
data. The authentication format for different authentication types is specified in the description of the 
Activate Session command. For multi-session connections, the starting Outbound session sequence that 
the BMC is to use when sending packets to the remote console is also passed in the request. (Session 
sequence numbers are explained in the next section.) 


6. The BMC uses the temporary Session ID to look up the information for the user that was identified in 
the Get Session Challenge request. The BMC looks up the user’s password/key data, and potentially 
other data such as a stored copy of the earlier challenge string, and uses it to verify that the packet 
signature or password is correct. If so, the BMC issues an Activate Session response that provides the 
Session ID to use for the remainder of the session. For multi-session connections, the Activate Session 
response is itself authenticated (signed). The BMC will also deliver the starting Inbound session 
sequence that the Remote Console is to use when sending packets to the BMC. 


From this point, whether individual packets for the session are authenticated or not is based on settings such as the 
Per User Authentication and User Level Authentication parameters. Refer back to 6.12.4, Per-Message and User 
Level Authentication Disables. 


6.12.8 IPMI v1.5 Session Sequence Numbers 


The session sequence number is a 32-bit, unsigned, value. The session sequence number is not used for 
matching IPMI requests and responses. The IPMI Sequence (Seq) field or similar field in the particular payload 
is used for that purpose. The sender of the packet increments the session sequence number for every packet that 
gets transmitted even if the payload of the content is a ‘retry’. Session Sequence Numbers are generated and 
tracked on a per-session basis. Le there are separate sets of sequence numbers and sequence number handling 
for each session. 


Sequence numbers only apply to packets that are transmitted within the context of an IPMI session. Certain 
IPMI commands and protocol messages are accepted ‘outside of a session’. When sent outside a session, the 
sequence number fields for these packets are always set to 0000 0000h. 


6.12.9 IPMI v1.5 Session Sequence Number Handling 


For IPMI v1.5 sessions, there are two Session Sequence Numbers: the Inbound Session Sequence Number and 
the Outbound Session Sequence Numbers. The inbound and outbound directions are defined with respect to the 
BMC. Inbound messages are from the remote console to the BMC, while outbound messages are from the BMC 
to the remote console. 


Inbound messages use the inbound session sequence number, while outbound messages use the outbound 
session sequence number. The inbound and outbound sequence numbers are updated and tracked independently, 
and are unique to each session. Since the number of incoming packets and outgoing packets will typically vary, 
the inbound and outbound sequence numbers will not stay in lock step with one another. 


The BMC and the remote console independently select the starting session sequence number for the messages 
they receive. Typically, this is done using a random number in order to further reduce the likelihood of a 
playback attack. The remote console sets the starting values for the outbound session sequence number when it 
sends the first Activate Session command for an authenticated session. The remote console must increment the 
inbound session sequence number by one (1) for each subsequent message it sends to the BMC. The Activate 
Session response is the first authenticated outbound (BMC to remote console) message. This response message 
uses the initial outbound session sequence number value that the remote console delivered in the prior Activate 
Session command request. The BMC must increment the outbound session sequence number by one (1) for 
each subsequent outbound message from the BMC. 
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6.12.10 IPMI v1.5 Inbound Session Sequence Number Tracking and Handling 


At a minimum, the BMC is required to track that the inbound sequence number is increasing, and to silently 
discard the packet if the sequence number is eight counts or more from than the last value received. (An 
implementation is allowed to contain a proprietary configuration option that enables a larger sequence number 
difference, as long as the standard of +eight can be restored.) 


An implementation can elect to terminate the session if it receives a number of sequence numbers that are more 
than eight counts from the last value received. 


Valid packets (packets with good data integrity checks and signature) to a given session that have the same 
inbound sequence number as an earlier packet are considered to be duplicate packets and are silently discarded 
(even if the message content is different). 


6.12.11 IPMI v1.5 Out-of-order Packet Handling 


In order to avoid closing a session because a packet was received out-of-order, the BMC must implement one of 
two options: 


Option 1: Advancing eight-count (or greater) window. Recommended. Track which packets have been 
received that have sequence numbers up to eight counts /ess than the highest last received sequence 
number, tracking which of the prior eight sequence numbers have been received. Also accept packet with 
sequence numbers that are up to eight counts greater than the last received sequence number, and set that 
number as the new value for the highest sequence number received. This option is illustrated in Appendix A 
- Previous Sequence Number Tracking. 


Option 2: Drop any packets with sequence numbers that are lower than the last valid value received. While 
simpler than option 1, this option is not recommended except for resource-constrained implementations due 
to the fact that any out-of-order packets will require the remote console to timeout and retransmit. 


Sequence number wrap-around must be taken into account for both options. When a sequence number advances 
from FFFF_FFFFh to 0000_0000h, the value FFFF_FFFFh represents the lesser sequence number. 


6.12.12 IPMI v1.5 Outbound Session Sequence Number Tracking and Handling 


The remote console is required to handle outbound session sequence number tracking in the same manner as the 
BMC handles the inbound session sequence number, except that Option 2 (above) should not be used as a 
means of handling out-of-order packets. 


6.12.13 IPMI v2.0 RMCP+ Session Sequence Number Handling 
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For IPMI v2.0 RMCP+ sessions, there are two sets of Session Sequence Numbers for a given session. One set 
of inbound and outbound sequence numbers is used for authenticated (signed) packets, and the other set is used 
for unauthenticated packets. The inbound and outbound sequence numbers for authenticated packets are 
updated and tracked independently from the inbound and outbound sequence numbers for unauthenticated 
packets. 


IPMI v2.0 RMCP+ Session Sequence Numbers are used for rejecting packets that may have been duplicated by 
the network or intentionally replayed. 


The individual Session Sequence Numbers is are initialized to zero whenever a session is created and 
incremented by one at the start of outbound processing for a given packet (i.e. the first transmitted packet has a 
“1” as the sequence number, not 0). Session Sequence numbers are incremented for every packet that is 
transmitted by a given sender, regardless of whether the payload for the packet is a ‘retry’ or not. 


When dropping packets because of sequence number, any packet with an illegal, duplicate, or out-of-range 
sequence can be dropped without having to verify the packet integrity data (AuthCode) signature first. When 
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accepting packets, the BMC must apply any packet integrity and authentication code checks before accepting 
the packet’s sequence number. 


6.12.14 IPMI v2.0 RMCP+ Sliding Window 


IPMI v2.0 RMCP+ uses a ‘sliding window’ for tracking sequence numbers for received packets. This sliding 
window is used for rejecting packets that have sequence numbers that are significantly out-of-range with respect 
to the sequence number for the most recently accepted packet while allowing a number of out-of-order packets 
to be accepted. 


In order for a packet to be accepted by the BMC, its sequence number must fall within a 32-count sliding 
window, where packets will be accepted if they are within plus 15 or minus 16 counts of the highest sequence 
number that was previously accepted, and they are not duplicates of any previously received sequence numbers. 


6.12.15 Session Inactivity Timeouts 


A session is automatically closed if no new, valid, message has been received for the session within the 
specified interval since the last message. The session must be re-authenticated to be restored. A remote console 
can optionally use the Activate Session command to keep a session open during periods of inactivity. 


Note that only an active session will keep the Session Inactivity Timeout from expiring. IPMI message activity 
that occurs outside of an active session has no effect. This is to prevent someone from keeping a phone 
connection indefinitely while trying to guess different passwords to activate a session. 


The BMC only monitors for inactivity while the connection is switched over to the BMC. Note that closing a 
session is not always the same as hanging up a modem connection. Serial/modem sessions are also 
automatically closed when the connection is switched over to the system, but the phone connection remains 
active. The BMC only terminates the phone connection if a session is closed due to an inactivity timeout while 
the serial connection is routed to the BMC. 


The timeout and tolerance values are specified for the management controller (BMC) that will timeout and close 
the session. System software should take this tolerance into account, plus any additional delays due to media 
transmission times, etc. 


An implementation can provide an option to allow the timeout to be configurable via a parameter in the 
configuration parameters for the given channel type. 


Table 6-, Default Session Inactivity Timeout Intervals 


Session Type Default Tolerance Notes 
Expiration 
Interval 
LAN 60 seconds +/- 3 seconds 
Direct Connect Mode Serial 60 seconds +/- 3 seconds 
Modem Mode Serial 60 seconds +/- 3 seconds | The Inactivity Timeout Interval starts 


whenever a connection is established with, 
or switched to, the BMC. The Phone 
connection gets terminated if inactivity 
timeout occurs while serial connection is 
routed to BMC. 


6.12a Avoiding ‘Slot Stealing’ 


It is highly recommended that an implementation provide a mechanism for protecting against someone 
accidentally or maliciously ‘claiming’ all the session slots and subsequently locking out access to the BMC. For 
example, this could occur by an errant program repeatedly issuing Get Session Challenge commands without 
successfully activating a session - causing all available resources for tracking pending sessions to be used up. 
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One possible solution is to use an LRU algorithm that drops the Session ID for the oldest Session ID that has a 
pending ‘Activate Session’. That way, the only way to ‘permanently’ use up slots is by activating and 
maintaining sessions for all session slots. A minor refinement may be to provide a few seconds of delay on 
returning the response to the Get Session Challenge in order to give opportunity for a well-behaved application 
to get a Challenge and return an Activate Session command before the errant software re-issued another Get 
Session Challenge. (This is only an improvement for errant applications that wait for the response to the Get 
Session Challenge before issuing the request again.) 


6.12.16 Additional Session Specifications and Characteristics 
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At least four simultaneous sessions should be supported on a given channel. 


By default, sessions are automatically closed if no valid activity is detected within the Session Inactivity 
Timeout Interval, or if the connection or link is terminated. Valid activity is defined as the receipt of a valid 
IPMI message for that session while the connection is routed to the BMC. 


At least four pending bridged requests should be supported for each bridged interface that requires the BMC 
to track pending responses. See 6.13, BMC Message Bridging for more information. 


The typical BMC is expected to allow only a small number of simultaneous open sessions (on the order of 
four to eight). Thus, remote console applications should avoid activating multiple sessions whenever 
possible, in order to allow other remote consoles to also get access. 


The Activate Session command will return a completion code indicating whether the request was rejected 
because BMC is presently busy with other open sessions. 


The specification allows multiple sessions to be activated from a single IP address. The primary reason for 
allowing multiple sessions is to allow a system to serve as a proxy agent that provides BMC access for 
remote consoles that connect to it instead of directly to the BMC. 


Multiple sessions are not intended to be used to support access by multiple applications behind an IP 
address. If multiple applications require access to the BMC on a given system, a single driver or ‘middle- 
ware’ should coordinate that access and use a single session, if possible. The IPMI Software ID and the 
IPMI sequence number are two fields that a shared driver can used to identify and route messages to and 
from a given application. 


There is a 1:1 relationship between a user name and a session. Le different usernames cannot share the 
same session. However, multiple sessions can be activated using the same username. 


All sessions start off at User Level privilege. It is necessary to issue a Set Session Privilege to raise the 
operating privilege level before commands that required higher privilege can be executed. The maximum 
operating privilege for a session is determined by Privilege Limits that are set both for the user and for the 
overall channel. The more restrictive setting of the User Privilege Limit and the Channel Privilege Limit sets 
the maximum operating privilege available for a session. 


An Operator can optionally use the Get Channel Info and Get Session Info commands to retrieve the address 
of parties with open sessions and their present privilege level. This is to allow a remote console to 
coordinate with another remote console that already has an active session. This can be used to allow 
software to coordinate access to the system. For example, if management software running at Console “A” 
wished to remotely reset a given system, it could first see whether another console had an active session 
with the system to be reset. It could then use information from the Get Channel Info and Get Session Info 
commands to send a message directly to the other console, notifying it of the pending reset. 


An Administrator can force sessions on any channel to be terminated. 
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6.13 BMC Message Bridging 


BMC Message Bridging provides a mechanism for routing IPMI Messages between different media. Bridging is 
only specified for delivering messages between different channels; i.e. it is not specified for delivering messages 
between two sessions on the same channel. 


In IPMI 1.0, bridging was primarily specified just for providing access between SMS (System Interface) and the 
IPMB. With IPMI 1.5, these mechanisms have been extended to support delivering IPMI messages between 
active connections / sessions on any IPMI Messaging media connected to the BMC. 


There are three mechanisms for bridging messages between different media connected to the BMC, depending on 
what the target of the message is: 


e BMC LUN 10b is used for delivering messages to the System Interface. The BMC automatically routes any 
messages it receives via LUN 10b to the Receive Message Queue. 


e Send Message command from System Interface is used for delivering messages to other channels, such as 
the IPMB. The messages appear on the channel as if they’ve come from BMC LUN 10b. Thus, if the message 
is a request message, the response will go to BMC LUN 10b and the BMC will automatically place the 
response into the Receive Message Queue for retrieval. System software is responsible for matching the 
response up with the original request, thus the ‘No Tracking’ setting in the Send Message command is used. 


e Send Message command with response tracking. This format of Send Message command is used with 
response tracking for bridging request messages to all other channels except when the System Interface is the 
source or destination of the message. 


The following sections provide additional information on the operation and use of these bridging mechanisms. 


6.13.1 BMC LUN 10b Routing 


Because messages to SMS are always routed to the Receive Message Queue, the Send Message command is not 
typically used to send messages to SMS. Instead, messages to SMS are delivered via the BMC SMS LUN, 10b. 
The BMC automatically reformats and places any messages that are addressed to LUN 10b into the Receive 
Message Queue for SMS to retrieve using the Get Message command. 


Thus, sending a request to SMS just requires formatting the command so that it is addressed to BMC LUN 10b. 
SMS can retrieve the request from the Receive Message Queue, extract the originator’s address and channel 
info, and then use the Send Message command to deliver a response. 


The BMC does not track requests and responses for messages to system software because the Receive Message 
Queue provides the channel and session information necessary to format the Send Message command to deliver 
the response. Similarly, system software is capable of tracking the channel and session information it used when 
generating a request. Thus, the ‘No Tracking’ option is used for Send Message commands from system 
software. 


The responder then delivers its response message to BMC LUN 10b and the response gets routed to the Receive 
Message Queue. Conversely, if a channel wants to deliver a message to SMS, it sends the request message to 
BMC LUN 10b, and later SMS uses a Send Message command to return the response from BMC LUN 10b. 


6.13.2 Send Message Command From System Interface 


The operation of the Send Message command when issued via the System Interface is different than when the 
Send Message command is issued from other interfaces. This is because the IPMI System Interfaces were 
specified as always returning an immediate command response. In order to avoid tying up the System Interface 
waiting for a bridged response, a response to the Send Message command is returned as soon as the request is 
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bridged to the target channel. This response only indicates that the Send Message command was executed. It is 
not the response to the bridged request. 


Later, the response to the bridged request is received by the BMC and routed into the Receive Message Queue 
and it is retrieved using a Get Message command. For example, here are the typical steps involved in delivering 
a request from the System Interface to a device on the IPMB, and receiving a corresponding response: 


1. System software formats a Send Message request that encapsulates information for the request to be 
placed on IPMB. The requester’s LUN in the data is set to 10b so when the response comes back, the 
BMC will place it in the Receive Message Queue. The encapsulated request is also given a sequence 
number by the system software. System software will use this number later, along with other fields, to 
match up the Receive Message Queue data with the original request. 


2. System software delivers the Send Message request to the BMC via the System Interface. 


3. The BMC returns an ‘OK’ response to the Send Message command, indicating that it has received the 
request and delivered it to the IPMB. 


4. Sometime later, the target IPMB device delivers a response to the request. The response is sent back to 
the same requester’s LUN that was used in the request, 10b. The BMC routes message data received 
on 10b to the receive message queue, and also tags it with information such as the channel number that 
the message was received from. 


5. System software detects that there is data in the Receive Message Queue. This is either done by polling 
for messages by periodically checking the SMS_ATN bit, or for interrupt driven implementations, 
getting an interrupt when SMS_ATN becomes set. Software then uses the Get Message Flags 
command to discern whether the SMS_ATN condition was from getting data into the Receive Message 
Queue or some other event. 


6. System software then issues a Get Message request. The response returns a message from the queue. If 
the data is for a response, software then checks the message fields, such as sequence number, channel 
number, CMD, etc., to see if the response matches up with an earlier request. In this example, software 
would be looking for a response to the request it had bridged onto IPMB. If the Receive Message 
Queue holds a request for system software, it processes it accordingly. 


7. If software has not received a response by the timeout intervals specified for IPMB, it can retry the 
request. Also note that IPMB sequence numbers generally expire after 5 Seconds. This number comes 
from the sequence number expiration interval on IPMB. Software can generally discard requests that 
are more than 5 seconds old and re-use their sequence numbers. 


If the target channel uses sessions, the Send Message command data will require a Session Handle value to 
select which session on the channel the message will be sent to. Software can use the Get Channel Info and Get 
Session Info commands to determine what channels are present and to obtain the Session Handle for a given 
session. 


6.13.3 Send Message Command with Response Tracking 
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The Send Message command is used primarily to direct the BMC to act as a proxy that translates a message 
from one IPMI messaging protocol to another. The BMC formats the data for the target channel type and 
protocol and delivers it to the selected medium. 


Media such as the IPMB do not include channel number and session information as part of their addressing 
information. As a result, request messages from another channel must be delivered as if they originated from the 
BMC itself. 


If the bridged message is a request, it is necessary for the BMC to hold onto certain data, such as originating 
channel and session information, so that when the response message comes back it can reformat the response 
and forward it back to the originator of the request. The primary way the BMC accomplishes this is by 
assigning a unique sequence number to each request that it generates, and saving a set of information in a 
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‘Pending Bridged Response’ table that is later used to reformat and route a response back to the originator of 
the request. 


The sequence number returned in the response is then used to look up who generated the original response, plus 
the saved formatting and addressing information. The BMC then reformats and delivers the response to the 
original requester and deletes the request from its list of ‘pending responses’. The Send Message command 
includes a parameter that directs the BMC to save translation information for and track outstanding request 
messages for the purpose of routing the response back to the originator of the Send Message command. 


Note that, with the exception of messages to SMS, when the Send Message command is used to deliver a 
message to a given medium the message appears to have been originated by the BMC. This means that a 
controller on the IPMB can’t generically distinguish a bridged request from SMS from a bridged request from 
LAN. 


Table 6-, Message Bridging Mechanism by Source and Destination 


BMC tracks 
Delivery pending 

Message Type and direction Mechanism responses 
Request or Response from System Interface to any other channel Send Message no 
Request or Response to System Interface from any other channel BMC LUN 10b no 
Request from any channel except System Interface to IPMB Send Message yes 
Response from IPMB to any channel except System Interface BMC LUN 00b yes 
Request from any channel (except System Interface) to PCI Send Message yes 
Management Bus 
Request from PCI Management bus to any channel except System BMC LUN 00b yes 
Interface 
Request from Serial to LAN Send Message yes 
Response LAN to Serial BMC LUN 00b yes 
Request from LAN to Serial Send Message yes 
Response from Serial to LAN BMC LUN 00b yes 


6.13.4 Bridged Request Example 
The example illustrates a Send Message command from LAN being used to deliver a request to IPMB. 


Bridged requests to the IPMB can come from several different channels: LAN, serial/modem, and the ICMB. 
The BMC uses the sequence number that it places on the bridged request to identify which channel and to 
which address on that channel the response is to go back to. It is therefore important for the BMC to ensure that 
unique sequence numbers are used for pending requests from the different channels. It is also important that 
sequence numbers are unique for successive requests to a given responder. One way to manage sequence 
numbers to the IPMB is to track sequence numbers on a per responder basis. This can be kept in a table of 
‘Pending Bridged Response’ info. 


In order to get the response back to the LAN, the IPMB response must return the same sequence number that 
was passed in the request. (This is a basic rule of IPMI Messaging, so there’s nothing special about that 
requirement.) The management controller uses the sequence number to look up the channel type specific 
addressing, sequence number, and security information that it stored when the request was forwarded. For 
example, if the channel type is ‘LAN’ then the response message must be formatted up in an RMCP/UDP 
packet with the IP address of the requester, the sequence number passed in the original request, the appropriate 
security ‘key’ information, etc. 


When a request message is bridged to another channel by encapsulating it in a Send Message command (from a 
source channel other than the system interface), the BMC immediately returns a response to the Send Message 
command itself. Meanwhile, the request is extracted from the Send Message command and forwarded to the 
specified target channel. 
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The Send Message command must be configured to direct the BMC to keep track of data in the request so when 
the response comes back from the target device it can be forwarded by the BMC back to the channel that 
delivered the original Send Message command to the BMC. When the response comes back from the target, the 
BMC uses the tracking information to format the response for the given channel. To the party that initiated the 
Send Message command, the response will appear as if the encapsulated request was directly executed by the 
BMC. Le. it will look like an asynchronously generated response message. 


For example, suppose a Get Device ID command has been encapsulated in a Send Message command directed 
to the IPMB from a LAN channel. The BMC will immediately send a response to the Send Message command 
back on LAN. The BMC will extract the encapsulated Get Device ID message content and format it as a Get 
Device ID request for IPMB. The target device on IPMB responds with a Get Device ID response message in 
IPMB format. The BMC takes the tracking information that was stored when the Send Message command was 
issued, and uses it to create a Get Device ID response in LAN format. The Responder’s address information in 
that response can either be that of the BMC, or the address of the device on IPMB that the request was targeted 
to, at the choice of the BMC implementation. Parties that initiate this type of bridged request using the Send 
Message command should accept responses from the BMC that use either address. 


The following figure and steps present an example high-level design for handling a bridged request. Note that 
the example shows information that is generated and stored, but it does not show any particular code module 
that would perform that operation. That is, the choice of which functions are centralized, which are in a ‘LAN’ 
module, and which are in an ‘IPMB’ module (or whether you even have such modularity) is left to the 


implementer. 
Figure 6-, LAN to IPMB Bridged Request Example 
LAN REQUEST Encapsulated data for IPMB Request 
| Source | Session | Responder's Requester's CMD = Responder's 
\ıpımac | mp Address Cer Re Address ewe Send Address (RsA) 
| Address | (0047h) | (RsA) [BMC] (RaA) q Message e.g. 24h 


0047h 


(9 N 
(2) 
Destination Source Session Requester's Destination/ Channel 
— Channel Channel ID Address/ Channel 
Cho RqSeq# Number Handle SWID Number 
(IPMB) 
Seq #s 
2 Seq # A E š 
Allocator > Based Internally Stored Info for tracking 
Chi 0017h |Ch1| 3 | AAh | Ch 24h 00b | (RqA) RQLUN Sensor and formatting response back to 
Seq #s Reading requester 


fen 


OF Ge Saal 


esponder's letFn eg S 
Responders | NetFn/ Seenen | Dë | om. 
Slave Addr. RsLUN Chkt* ROSA RqLUN Get Sensor Sensor Chk2* 
(RsSA) =S/E, | ZE, Ge LUN= Reading | Number | “= 
=24h 00b (BMC) 17h*/ 00b' 


1. When the BMC receives the Send Message command with the ‘Bridged Request’ parameter bit set, it checks 
for an available entry in a Pending Bridged Response table and copies parameters from the request to be 
bridged. When the response comes back, these parameters will be used to validate that the response matches 
the earlier request and to reformat the response for the originating channel. The bold outlined boxes 
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represent parameters and data in the Send Message command that will ultimately be copied to the resulting 
request on the target channel (the IPMB in this example). 


2. Any channel session information necessary to get the response back to the original requester will also need 
to be recorded. In this example, the BMC maintains a separate table of session information for the LAN 
channel. An offset into that table is used as a ‘handle’ for identifying the session information associated with 
the request. This handle is used in the Pending Bridged Response table in lieu of copying all the session 
information. Note that with such an implementation, it is important to remember details such as invalidating 
and freeing any bridge table entry associated with that session if the session should get closed while 
responses are pending. 


3. In this example, the BMC has a separate ‘Sequence Number Allocator’ routine that ensures that sequence 
numbers used in bridged requests are kept unique for a given channel. This is done so when the response 
comes back, the sequence number can be used to look up the corresponding request info entries from the 
Pending Bridged Response table. 


4. Responses have a five second ‘sequence number expiration’ interval. If a response is not received by the 
expiration interval, the corresponding entry in the Pending Bridged Response entry is deleted and the 
sequence number associated with the request can be reused. The Seq # Expiration column in this example 
represents a possible implementation where the Seq # Expiration value is decremented nominally once every 
10 ms. The entry is considered to be free when the number hits 0. Thus, in this example the Seq # Expiration 
field could be used both for tracking sequence number expiration as well as a mechanism for marking 
whether a table entry is available or not. 


5. The BMC takes the indicated values and uses them to construct the bridged request. The request is a 
combination of field values copied from the original Send Message command and values generated by the 
BMC. The BMC generated values are shown with a bold underlined typeface with an asterisk. 


6.14 Message Size & Private Bus Transaction Size Requirements 


The following table summarizes the message size and transaction size requirements for the various interfaces to 
the BMC and IPMI Management controllers. The IPMI message sizes include any IPMI-level addressing and data 
integrity information required for the interface. For example, the IPMB Message lengths include the requester and 
responder addressing information, sequence number, and checksums. The message sizes do not include counts for 
additional encapsulation, data escaping, or framing used to transport the IPMI message on the given media. 


The IPMB standard overall message length for ‘non-bridging’ messages is specified as 32 bytes, maximum, 
including slave address. This sets the upper limit for typical IPMI messages. With the exception of messages used 
for bridging messages to other busses or interfaces (e.g. Master Write-Read and Send Message) IPMI messages 
should be designed to fit within this 32-byte maximum. In order to support bridging, the Master Write-Read and 
Send Message commands are allowed to exceed the 32-byte maximum transaction on IPMB. 


Refer to 
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Appendix D - Determining Message Size Requirements for information on how these values were derived. 
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Table 6-, IPMI Message and IPMB / Private Bus Transaction Size Requirements 


Interface 
KCS/SMIC Input 


Requirement Description 


Required: 


40 bytes IPMI Message, minimum 


KCS/SMIC Output 


Required: 


38 bytes IPMI Message, minimum 


BT Input 


Required: 


42 bytes IPMI Message, minimum, (including BT Interface ‘length’ 
byte). The BT interface has length and Seq fields in addition to the 
fields used by the KCS and SMIC interfaces. This adds two bytes to 
the message size support requirements. 


BT Output 


Required: 


40 bytes IPMI Message, minimum, (including BT Interface ‘length’ 
byte) 


IPMB Input 


Required: 
Recommended: 


32 bytes IPMI Message, minimum (including slave address) 

36 bytes bus transaction, minimum (including slave address), to 
support an OEM option to allow the BMC to be the target of an SMBus 
2.0 Block-Write with PEC. 


IPMB Output 


Required: 


36 bytes bus transaction, minimum (including slave address) to allow 
the BMC to be able to issue access slave devices that use the SMBus 
2.0 Block-Write with PEC protocol. Note that the IPMB standard 
message length is shorter than the SMBus 2.0 message. 


The IPMB standard message length is specified as 32 bytes, 
maximum, including slave address. 


SMBus 2.0 Input 


Required: 


36 bytes bus transaction, minimum (including slave address) to allow 
the BMC to be target of an SMBus 2.0 Block-Write with PEC protocol 
transaction. 


SMBus 2.0 Output 


Required: 


36 bytes (including slave address) to allow the BMC to generate an 
SMBus 2.0 Block-Write with PEC transaction. 


Private Bus Input 


Recommended: 


34 bytes bus transaction, minimum, if the Private Bus is implemented 
as a physical I#C or SMBus. The 34 bytes supports accessing slave 
devices that use the SMBus 2.0 Block-Read protocol. (The count 
excludes any slave address, since for this type of transaction the slave 
address is output by the management controller, rather than being an 
input to the management controller.) 


Private Bus Output 


Required: 


Recommended: 


23 bytes This is only required when a controller indicates that it has a 
Private Bus that includes FRU SEEPROMs that are accessible via the 
Master Write-Read command must support a Master Write-Read 
command equivalent to the largest Master Write-Read command that 
could be delivered as a 32-byte IPMB message. 


Otherwise, the Private Bus is only required to support the transaction 
size required for the private or OEM devices that are used in the 
particular implementation. 


An implementation will typically implement a private bus using an 
actual I?C or SMBus connection. However, the private bus 
implementation could be ‘virtual’ - where the management controller 
responds to the Master Write-Read command as if a physical private 
bus were present. For a physical private bus implementation, a 32- 
byte Master Write-Read command in IPMB format results in one byte 
of slave address and 22 bytes of write data going to the private bus. 
36 bytes bus transaction, minimum (including slave address). A 
private bus that truly implements a physical IC or SMBus interface 
should support system management software access to slave devices 
that use the SMBus 2.0 Block Write protocol. This means supporting a 
Master Write-Read command over the system interface that can be 
used to perform a full, 36-byte SMBus 2.0 Block-Write protocol 
transaction. 
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LAN/PPP Input 


Required: 


45 bytes IPMI Message content, minimum. IPMI LAN and PPP 
interfaces must accept an RMCP Packet containing an IPMI Message 
that would allow the remote console to submit a Master Write-Read 
message to perform an SMBus 2.0 Block-Write protocol transaction. 
Since the LAN interface uses a message format that follows the IPMB 
message format, there are additional bytes for source and destination 
addressing, sequence number, and checksums. 


LAN/PPP Output 


Required: 


42 bytes IPMI Message content, minimum. IPMI LAN and PPP 
interface must support delivering an RMCP Packet containing an IPMI 
Message that would allow the BMC to return the response to a Master 
Write-Read message that returns data from an SMBus 2.0 Block-Read 
protocol transaction. 
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7. IPMB Interface 


7.1 IPMB Access via Master Write-Read command 


When an IPMB is implemented in the system, the BMC serves as a controller to give system software access to 
the IPMB. The IPMB allows non-intelligent devices as well as management controllers on the bus. To support this 
operation, the BMC provides the Master Write-Read command via its interface with system software. The Master 
Write-Read command provides low-level access to non-intelligent devices on the IPMB, such as FRU 
SEEPROMS. 


The Master Write-Read command provides a subset of the possible I?C and SMBus operations that covers most 
PC/SMBus-compatible devices. 


In addition to supporting non-intelligent devices on the IPMB, the Master Write-Read command also provides 
access to non-intelligent devices on Private Busses behind management controllers. The main purpose of this is to 
support FRU SEEPROMS on Private Busses. 


7.2 BMC IPMB LUNs 


A BMC supports several LUNs (Logical Units) to which messages can be sent via the IPMB interface. These 
LUNs are used to identify different sub-addresses within the BMC that messages can be sent to. 


Table 7-, BMC IPMB LUNs 


BMC commands and Event Event Request Messages received on this LUN are routed to the Event 
Request Messages Receiver function in the BMC, and automatically logged if SEL logging 
is enabled . 


OEM LUN 1 OEM - reserved for BMC implementer / system integrator definition. 


SMS Message LUN Messages received on this LUN are routed to the Receive Message 
(Intended for messages to Queue and retrieved using a Read Message command. The 

System Management SMS Availflag is set whenever the Receive Message Queue has valid 
Software) contents. 


OEM LUN 2 OEM - reserved for BMC implementer / system integrator definition. 


7.3 Sending Messages to IPMB from System Software 


System Management Software (SMS) can use the BMC for sending and receiving IPMB messages. Both IPMB 
request and response messages can be sent and received using this mechanism. Therefore, not only can system 
software send requests to the IPMB and receive responses from the IPMB, it is also possible for system software 
to receive requests from the IPMB to send back IPMB responses. 


System software sends messages to the IPMB through the system interface using the BMC as an IPMB controller. 
This is accomplished by using the Send Message command to write the message to the IPMB (channel 0). The 
BMC does not place any restrictions on the type or content of the IPMB message being sent. System management 
software can send any IPMB request or response message it desires provided that the message meets the 
maximum length requirements of the Send Message command. 


System Management Software is responsible for providing all fields for the IPMB message, including Requester 
and Responder Slave addresses and checksums. The following figures show an example using the Send Message 
command to send a Set Event Receiver command to an IPMB device at slave address 52h, LUN 00b, via the 
system interface (see Table 29-, Set Event Receiver). The example command sets the Event Receiver address to 
20h = BMC. 
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The heavy bordered fields show the bytes for the IPMB message carried in the Send Message command. The 
requester’s LUN field (rqLUN) is set to 10b (BMC SMS LUN). This directs the responder to send the response to 
the Set Event Receiver command to the BMC’s Receive Message Queue. 
Figure 7-, IPMB Request sent using Send Message Command 
(06h = App request) (00b) (Send Message) | (00h) 
(52h = rsSA) ( 04h / 00b = Sensor/Event, LUN 00b) (9Eh) 
(20h = BMC) | (000001b/10b, 10b = SMS LUN) | (00h = Set Event Receiver) 
(20h = BMC) (00h) (BAh) 


Figure 7-, Send Message Command Response 
NetFn LUN Command Completion Code 
(07h = App response) (00b) (Send Message) (00h) 


Note that the response is for the Send Message command, not for the Set Event Receiver command. The response 
to the Set Event Receiver command will be returned later in the Receive Message Queue. System software uses 
the Get Message command to read messages from the Receive Message Queue. System software keeps track of 
any outstanding responses and matches responses up with corresponding requests as they come in. System 
software must also keep track of the protocol assigned to the particular channel in order to interpret the response 
to the Get Message command. 


7.4 Sending IPMB Messages to System Software 


It is possible for devices on the IPMB to autonomously send messages to system management software via the 
BMC. IPMB messages that are addressed to the SMS LUN (10b) in the BMC are placed into the Receive 
Message Queue. The contents can then be retrieved using the Get Message command. System management can 
then interpret the message and use the Send Message command to return a response. 


The BMC does not place any restrictions on the type of content of the IPMB message being received, as long as it 
is properly formatted, is addressed to the SMS LUN, and meets the maximum length requirements of the Get 
Message command. 


The BMC sets the corresponding ‘ATN’ flag in the system interface when a message is received into the Receive 
Message Queue. System software must poll for the ‘ATN’ flag, or receive an interrupt to determine that when a 
message is available. 


Event Messages can also be made directly available to system software via the optional Event Message Buffer and 
retrieved using the Read Event Message Buffer command. 


In the example shown in the preceding section, a Set Event Receiver command was sent out on the IPMB using 
the Send Message command. In the IPMB command, the requester’s slave address (rqSA) was set to 20h (BMC), 
and the requester’s LUN (rqLUN) set to 10b (SMS LUN). This means that the response will be sent to the SMS 
Message Buffer in the BMC. 
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The IPMB response to a Set Event Receiver command consists of just a Completion Code byte in the data portion 
of the IPMB message. Assuming a Completion Code of 00h = OK, the Receive Message Queue will eventually 
wind up a response message with the following contents: 


Figure 7-, Response for Set Event Receiver in Receive Message Queue 


NetFn | rqLUN 
(05h = Sensor/Event Response) | (10b = SMS LUN) (CAh) 
(52h) (000001b / 00b) (00h = Set Event Receiver) (00h = OK) (AAh) 
Note that this is the entire IPMB response message, with the leading slave address stripped off (the leading slave 
address does not need to be stored, since its known to be the BMC slave address = 20h). 


The response to the Get Message command would then look like the following. The heavy border fields show the 
data portion of the response that came from the Receive Message Queue. 


Figure 7-, Get Message Command Response 
NetFn i LUN Command Completion Channel 
(om = App response) | (007) 
NetFn | rqLUN 
(05h = Sensor/Event Response) : (10b = SMS LUN) 


rsSA rqSeq/rsLUN Cmd an Code Check 2 
(52h) (00000 1b / 00b) (00h = Set Event Receiver) (00h = OK) (AAh) 


7.5 Testing for Event Message Buffer Support 


System software must test for Event Message Buffer support. If software issues a Get BMC Global Enables 
command, and finds the buffer enabled, it can assume the controller supports the buffer. Otherwise, it must test by 
attempting to enable the Event Message buffer. 


If the BMC does not support the desired buffer, it shall return an Invalid Data Field (CCh) error completion code 
when an attempt is made to enable the respective buffer using the Ser BMC Global Enables command. An error 
completion code shall also be returned if an attempt is made to enable Event Message Buffer interrupts when that 
option is not supported. 
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8. ICMB Interface 


The ICMB Specification (see [ICMB]) describes the interfaces for implementing access via an ICMB Bridge 
Controller. ICMB was specified so that an ICMB Bridge controller could be added to an existing IPMI 
Implementation that contained an IPMB. 


In some implementations, the BMC can serve as the ICMB Bridge Controller. There are two ways to implement the 
interface for such a controller: 


a. Implement a virtual ICMB Bridge Controller within the BMC. 
b. (PMI v1.5 only) Implement the ICMB Bridge commands directly as BMC commands, but use IPMI v1.5 
channels and the Send Message command to replace the ICMB Bridge Request command. 


8.1 Virtual ICMB Bridge Device 


In this implementation, the ICMB Bridge Device functionality appears to system software as if there was a 
separate ICMB Bridge Controller on a physical IPMB. Instead, the BMC implements the ICMB Bridge Device 
functions internally on a ‘virtual IPMB’. This option can provide backward-compatibility with software that was 
designed to work with a non-integrated ICMB Bridge Device. 


The BMC reports that the Chassis Bridge Device is not part of the BMC by returning an address in the Get 
Chassis Capabilities that is different than the BMC address (20h). This indicates to software that it need to access 
the Bridge Device function by using Send Message commands to deliver messages to the Bridge Device via the 
primary IPMB. The BMC then monitors the Send Message command for messages directed to the Bridge Device 
address. When the BMC sees Send Message commands to the Bridge Device address, it handles them internally 
instead of routing them out to a physical IPMB. Responses from the virtual Bridge Device are placed into the 
Receive Message Queue as if they were received from the IPMB. 


It is optional for the BMC to provide ICMB access from the IPMB for this implementation. If such support is 
desired, there are two implementation options. The first option is for the BMC to respond to two slave addresses 
(the BMC address and the Bridge Device address). The second option is for the BMC to report the BMC address 
as the Bridge Device address whenever the Get Chassis Capabilities command is received from IPMB, and 
implement the bridge commands directly when accessed via the IPMB. 


8.2 ICMB Bridge Commands in BMC using Channels 


In this implementation, the BMC directly responds to the commands for the Chassis Bridge Device. The BMC 
reports its own address in the Get Chassis Capabilities command. This tells software that it does not need to use 
the Send Message command to encapsulate messages in order to access the Chassis Bridge function itself. This 
also tells software that is must use the Send Message command instead of the Bridge Request command. 


8.2.1 ICMB Bridging from System Interface to Remote IPMB using Channels 


The behavior with the Send Message command is somewhat different than the operation of the Bridge Request 
command implemented by a separated bridge controller on the IPMB. When the Bridge Request command was 
used to access the ICMB, the response to that command would hold the response from the ICMB. 


From the System Interface, bridging with the Send Message command is a multi-step operation: First you issue 
the Send Message command with the data to be sent to the ICMB. You then get a response to the Send Message 
command indicating that the data was successfully bridged onto the ICMB. This response does not contain the 
response data from the ICMB. Later (assuming that a request was bridged) the device on ICMB will respond 
and the response data will appear in the Receive Message Queue (if the System Interface was the source of the 
original Send Message command). The software can then use a Get Message command to retrieve the response 
message data. 
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The following tables show the KCS formats of the Send Message command request and response for bridging a 
request to a device on a remote IPMB and the later corresponding Receive Message Queue contents for the 
response from the remote device. 


Table 8-, System Interface Request For Delivering Remote IPMB Request via ICMB 
NetFn/RsLUN | App (even=Rq) / BMC LUN = 00b 


CMD Send Message 
Data 1 Channel Number = ICMB, track request = 1b 
Data 2 rqSeq = sequence number selected by system 
software / 00b 
Data 3:4 rmtBrXA 
Data 5 Bridge Request CMD 
Data 6 rsSA for remote IPMB device 
Data 7 netFn / rsLUN for remote IPMB device 
Data 8 CMD for remote IPMB device 
Data 9:N Data for remote IPMB device 
Checksum Checksum for Send Message Command 


Table 8-, Send Message Response 
NetFn/RsLUN | App (odd=Rs) / BMC LUN = 00b 


CMD Send Message 
Data 1 Completion Code for Send Message command 
Checksum Checksum for Send Message Command 


Table 8-2a, Get Message Response Data for Remote IPMB Request Delivered via ICMB 
NetFn/RsLUN | App (odd=Rs) / BMC LUN = 00b 


CMD Get Message 
Data 1 Completion Code for Get Message command 
Data 2 Channel Number = ICMB 
Data 3 rqSeq = Sequence number from original request 
/ 00b 
Data 4 rmtBr Completion Code 
Data 5 remote IPMB completion code 
Data 6:N remote IPMB data 
Checksum Checksum for Send Message Command 


8.2.2 ICMB Bridging from Local IPMB to Remote IPMB using Channels 
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From the IPMB, bridging with the Send Message command operates in a manner similar to the way it operates 
over the system interface. The main difference being that the device that originated the request later receives an 
asynchronous response message that appears as if the BMC is responding directly to the remote IPMB 
command. 


Note that the same rqSeq is used both in the response to the Send Message command and in the asynchronous 
response from the BMC. 


Bridging with this approach introduces a five-byte overhead on the request, and a O-byte overhead on the 
response. 
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Table 8-, IPMB Request For Delivering Remote IPMB Request via ICMB 


RsSA 20h (BMC) 
NetFn/RsLUN App (even=Rq) / 00b (BMC LUN) 
RqSA Address of local IPMB device issuing the request 
RqSeq/RqLUN | Sequence number selected by IPMB device 
issuing the request 
/ LUN of IPMB device issuing the request 
CMD Send Message 
Data 1 Channel Number = ICMB, track request = 1b 
Data 2:3 rmtBrXA 
Data 4 Bridge Request CMD (Tells BMC to deliver this 
to ICMB a message to be bridged to a remote 
IPMB) 
Data 5 rsSA for remote IPMB device 
Data 6 netFn / rel UN for remote IPMB device 
Data 7 Remote CMD (CMD for remote IPMB device) 
Data 8:N Remote Data (data for remote IPMB device) 
Checksum Checksum for Send Message Command 
Table 8-, Send Message Response 
RqSA Address of local IPMB device that issued the 
original request 
NetFn/RqLUN | App (odd-Rs) / LUN of device that issued the 
original request 
RsSA 20h (BMC) 
RqSeq / Sequence number from original request 
RsLUN / 00b (BMC LUN) 
NetFn/RsLUN | App (odd=Rs) / BMC LUN = 00b 
CMD Send Message 
Data 1 Completion Code for Send Message 
command 
Checksum Checksum for Send Message Command 


Table 8-, IPMB Response For Remote IPMB Request Delivered via ICMB 


RqSA Address of local IPMB device that issued the 
original request 
NetFn/RqLUN | App (odd-Rs) / LUN of device that issued the 
original request 
RsSA 20h (BMC) 
RaSeq / Sequence number from original Send Message 
RsLUN request 
/00b (BMC LUN) 
NetFn/RsLUN | App (odd=Rs) / BMC LUN = 00b 
CMD Remote CMD 
Data 1 Remote CMD Completion code 
Data 4:N Remote CMD data 
Checksum Checksum for Send Message Command 
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9. Keyboard Controller Style (KCS) Interface 


This section describes the Keyboard Controller Style (KCS) Interface. The KCS interface is one of the supported 
BMC to SMS interfaces. The KCS interface is specified solely for SMS messages. SMM messages between the 
BMC and an SMI Handler will typically require a separate interface, though the KCS interface is designed so that 
system software can detect if a transaction was interrupted. Any BMC-to-SMI Handler communication via the KCS 
interface is implementation specific and is not covered by this specification. 


The KCS Interface is designed to support polled operation. Implementations can optionally provide an interrupt 
driven from the OBF flag, but this must not prevent driver software from the using the interface in a polled manner. 
This allows software to default to polled operation. It also allows software to use the KCS interface in a polled mode 
until it determines the type of interrupt support. Methods for assigning and enabling such an interrupt are outside the 
scope of this specification. 


9.1 KCS Interface/BMC LUNs 


LUN 00b is typically used for all messages to the BMC through the KCS Interface. LUN 10b is reserved for 
Receive Message Queue use and should not be used for sending commands to the BMC. Note that messages 
encapsulated in a Send Message command can use any LUN in the encapsulated portion. 


9.2 KCS Interface-BMC Request Message Format 


Request Messages are sent to the BMC from system software using a write transfer through the KCS Interface. 
The message bytes are organized according to the following format specification: 


Figure 9-, KCS Interface/BMC Request Message Format 
Byte 1 Byte 2 Byte 3:N 


NetFn/LUN 


Where: 

LUN Logical Unit Number. This is a sub-address that allows messages to be routed to different 
‘logical units’ that reside behind the same physical interface. The LUN field occupies the least 
significant two bits of the first message byte. 

NetFn Network Function code. This provides the first level of functional routing for messages received 
by the BMC via the KCS Interface. The NetFn field occupies the most significant six bits of the 
first message byte. Even NetFn values are used for requests to the BMC, and odd NetFn values 
are returned in responses from the BMC. 

Cmd Command code. This message byte specifies the operation that is to be executed under the 
specified Network Function. 

Data Zero or more bytes of data, as required by the given command. The general convention is to 


pass data LS-byte first, but check the individual command specifications to be sure. 
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9.3 BMC-KCS Interface Response Message Format 


Response Messages are read transfers from the BMC to system software via the KCS Interface. Note that the 
BMC only returns responses via the KCS Interface when Data needs to be returned. The message bytes are 
organized according to the following format specification: 


Figure 9-, KCS Interface/BMC Response Message Format 
Byte 1 Byte 2 Byte 3 Byte 4:N 


NetFn/LUN Completion Code 


Where: 
LUN Logical Unit Number. This is a return of the LUN that was passed in the Request 
Message. 
NetFn Network Function. This is a return of the NetFn code that was passed in the Request 
Message. Except that an odd NetFn value is returned. 
Cmd Command. This is a return of the Cmd code that was passed in the Request Message. 


Completion Code The Completion Code indicates whether the request completed successfully or not. 


Data Zero or more bytes of data. The BMC always returns a response to acknowledge the 
request, regardless of whether data is returned or not. 


9.4 Logging Events from System Software via KCS Interface 


The KCS Interface can be used for sending Event Messages from system software to the BMC Event Receiver. 
The following figures show the format for KCS Interface Event Request and corresponding Event Response 
messages. Note that only Event Request Messages to the BMC via the KCS Interface have a Software ID field. 
This is so the Software ID can be saved in the logged event. 


Figure 9-, KCS Interface Event Request Message Format 


NetFn LUN Command Software ID (Gen ID) 1 
(04h = Sensor/Event Request) (00b) (02h = Platform Event) 7-bits 


Sensor Type Event Type | EventData 1 | Event Data 3 | Event Data3 


[1] Shading designates fields that are not stored in the event record. 


Figure 9-, KCS Interface Event Response Message Format 


NetFn Command Completion Code 
(05h = Sensor/Event Response) (02h = Platform Event) 


9.5 KCS Interface Registers 


The KCS Interface defines a set of I/O mapped communication registers. The bit definitions, and operation of 
these registers follows that used in the Intel 8742 Universal Peripheral Interface microcontroller. The term 
‘Keyboard Controller Style’ reflects the fact that the 8742 interface is used as the system keyboard controller 
interface in PC architecture computer systems. 


The specification of the KCS Interface registers is given solely with respect to the ‘system software side’ view of 
the interface in system I/O space. The functional behavior of the management controller to support the KCS 
Interface registers is specified, but the physical implementation of the interface and the organization of the 
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interface from the management controller side is implementation dependent and is beyond the scope of this 
specification. 


On the system side, the registers are mapped to system I/O space and consists of four byte-wide registers. 
e Status Register - provides flags and status bits for use in various defined operations. 
e Command Register - provides port into which ‘Write Control Codes’ may be written. 
e Data In - provides a port into which data bytes and ‘Read Control Codes’ may be written. 
e Data Out - provides a port from which data bytes may be read. 


The default system base address for an I/O mapped KCS SMS Interface is CA2h. Refer to Appendix C1 - 
Locating IPMI System Interfaces via SM BIOS Tables for information on using SM BIOS tables for describing 
optional interrupt usage, memory mapped registers, 32-bit and 16-byte aligned registers, and alternative KCS 
interface addresses. Software can assume the KCS interface registers are I/O mapped and byte aligned at the 
default address unless other information is provided. 


Figure 9-, KCS Interface Registers 


7 6 5 0 VO address 


4 3 2 1 
Status (ro) S0 C/D# | SMS_ATN base+1 
2 1 


Command (wo) [baser] 
Data Out (ro) [i base» 
Data In (w) LL base 


Reserved bits must be written as ‘0’ and ignored during reads. Software should not assume that 
reserved bits return a constant value. 


9.6 KCS Interface Control Codes 


Control codes are used for ‘framing’ message data transferred across the KCS Interface. Control Codes are used 
to: 


e Identify the first and last bytes of a packet. 
e Identify when an error/abort has occurred. 


e Request additional data bytes. 


9.7 Status Register 


System software always initiates a transfer. If the BMC has a message for SMS, it can reguest attention by setting 
the SMS ATN bit in the status register. System software then detects the flag and initiates the transfer. 


Other bits in the status register are used to arbitrate access to the command and data registers between the BMC 
and system software and to indicate the “state” (write, read, error, or idle) of the current transaction. The 
following tables summarize the functions of the Status Register bits. 
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Table 9-, KCS Interface Status Register Bits 
ee 


State bit 1. Bits 7 & 6 are used to indicate the current state of the KCS Interface. 
Host Software should examine these bits to verify that it’s in sync with the BMC. 
See below for more detail. 


| 6 | SO | State bit 0. See bit 7. 
| 5 |  OEM2 OEM - reserved for BMC implementer / system integrator definition. 
OEM1 OEM - reserved for BMC implementer / system integrator definition. 


3 C/D# Specifies whether the last write was to the Command register or the Data In 
register (1=command, O-data). Set by hardware to indicate whether last write 
from the system software side was to Command or Data In register. 


2 SMS_ATN | Set to 1 when the BMC has one or more messages in the Receive Message 
Queue, or when a watchdog timer pre-timeout, or event message buffer full 
condition exists]. OEMs may also elect to set this flag is one of the OEM 1, 2, 
or 3 flags from the Get Message Flags command becomes set. 
This bit is related to indicating when the BMC is the source of a system 
interrupt. Refer to sections 9.12, KCS Communication and Non-communication 
Interrupts, 9.13, Physical Interrupt Line Sharing, and 9.14, Additional 
Specifications for the KCS interface for additional information on the use and 


requirements for the SMS_ATN bit. 


1 IBF Automatically set to 1 when either the associated Command or Data In register | R/O 
has been written by system-side software. 
Ed EE Set to 1 when the associated Data Out register has been written by the BMC. 


R/W direction is with respect to the system side of the interface. Reads move data from the BMC to system software, 
writes move data from system software to the BMC. 

2. The event message buffer full condition contributes to SMS_ATN only if the event buffer full condition is intended to 
be handled by system management software. Otherwise, the event message buffer full condition should not 
contribute to SMS_ATN. For interrupt driven interfaces, the condition is required to contribute to SMS_ATN if the 
event message buffer full condition generates the same interrupt as the KCS Communications interrupt. 


Bits 7:6 are state bits that provide information that is used to ensure that the BMC and system software remain in 
sync with one another. Following are the possible states and their meaning: 


Table 9-, KCS Interface State Bits 


S1 so 
(bit 7) (bit 6) Definition 


ro | 0 | IDLE STATE. Interface is idle. System software should not be expecting nor sending any data. 


1 READ STATE. BMC is transferring a packet to system software. System software should be in the 
"Read Message” state. 


1 WRITE STATE. BMC is receiving a packet from system software. System software should be 
writing a command to the BMC. 
1 1 


ERROR STATE. BMC has detected a protocol violation at the interface level, or the transfer has 
been aborted. System software can either use the “Get Status' control code to request the nature 
of the error, or it can just retry the command. 
Note: Whenever the BMC is reset (from power-on or a hard reset), the State Bits are initialized to "11 - Error State”. Doing so 
allows SMS to detect that the BMC has been reset and that any message in process has been terminated by the BMC. 


9.7.1 SMS ATN Flag Usage 


The SMS ATN flag is used to indicate that the BMC requires attention from system software. This could either 
be because a message was received into the Receive Message Queue and ready for delivery to system software, 
the Event Message Buffer is full (if the Event Message Buffer is configured to generate an interrupt to system 
management software), a watchdog pre-timeout occurred, or because of an OEM event. Flags in the BMC 
identify which conditions are causing the SMS_ATN flag to be set. All conditions must be cleared (i.e. all 
messages must be flushed) in order for the SMS_ATN bit to be cleared. 
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The SMS_ATN bit is also used when the KCS interface is interrupt driven, or when OEM events or watchdog 
pre-timeouts generate a system interrupt. Refer to sections 9.12, KCS Communication and Non-communication 
Interrupts, 9.13, Physical Interrupt Line Sharing, and 9.14, Additional Specifications for the KCS interface for 
additional information on the use and requirements for the SMS_ATN bit. 


9.8 Command Register 


The Command register must only be written from the system side when the IBF flag is clear. Only 
WRITE_START, WRITE_END, or GET_STATUS/ABORT Control Codes are written to the command register. 


9.9 Data Registers 


Packets to and from the BMC are passed through the data registers. These bytes contain all the fields of a 
message, such as the Network Function code, Command Byte, and any additional data required for the Request or 
Response message. 


The Data_In register must only be written from the system side when the IBF flag is clear. The OBF flag must be 
set (1) before the Data_Out register can be read (see status register). 


9.10 KCS Control Codes 


The following table details the usage of ‘Control Codes’ by the KCS interface. 


Table 9-, KCS Interface Control Codes 
Code Description Target Output Data 
register Register 
60h GET STATUS / Request Interface Status / Abort Current Command Status Code 
ABORT operation 
61h WRITE_START Write the First byte Command N/A. 
of an Write Transfer 


EE 
of an Write Transfer 
| reserved å 


69h- reserved reserved 
6Fh 


Table 9-, KCS Interface Status Codes 


Description 


No Error 


Oih Aborted By Command (Transfer in progress was aborted by SMS issuing the Abort/Status 
control code) 


Illegal Control Code 


9.11 Performing KCS Interface Message Transfers 
System Management Software that uses the KCS Interface will typically be running under a multi-tasking 


operating system. This means transfers with the BMC may be interrupted by higher priority tasks or delayed by 
other System Management Software processing. The SMS channel handshake is optimized to allow the BMC to 
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continue to perform tasks between data byte transfers with System Management Software. The BMC does not 
time out data byte transfers on the SMS interface. 


Request and Response Messages are paired together as a Write Transfer to the BMC to send the request followed 
by a Read Transfer from the BMC to get the response. 


The process, as seen from the system perspective is depicted in Figure 9-6, KCS Interface SMS to BMC Write 
Transfer Flow Chart, and Figure 9-7, KCS Interface BMC to SMS Read Transfer Flow Chart, below. 


During the write transfer each write of a Control Code to the command register and each write of a data byte to 
Data_In will cause IBF to become set, triggering the BMC to read in the corresponding Control Code or data byte. 


If the KCS interface uses an interrupt, the BMC will write a dummy value of 00h to the output data register after it 
has updated the status register and read the input buffer. This generates an ‘OBF’ interrupt. The points at which 
this would occur are shown as “OBF” in Figure 9-6, KCS Interface SMS to BMC Write Transfer Flow Chart, 
below. 


During the read phase, each write of a READ Control Code to Data_In will cause IBF to become set, causing the 
BMC to read in the Control Code and write a data byte to Data_Out in response. If the KCS interface uses an 
interrupt, the write of the data byte to Data_Out will also generate an interrupt. The point at which this would 
occur during the READ STATE is shown as “OBF” in Figure 9-7, KCS Interface BMC to SMS Read Transfer 
Flow Chart, below. 


Note that software does not need to use the Get Status/Abort transaction to return the interface to the 
IDLE_STATE or handle an error condition. The interface should return to IDLE_STATE on successful 
completion of any full command/response transaction with the BMC. Thus, since the interface will allow a 
command transfer to be started or restarted at any time when the input buffer is empty, software could elect to 
simply retry the command upon detecting an error condition, or issue a ‘known good’ command in order to clear 
ERROR_STATE. 


9.12 KCS Communication and Non-communication Interrupts 


The following lists some general requirements and clarifications to support both KCS communication and KCS 
non-communication interrupts on the same interrupt line using the OBF signal. A KCS communications interrupt 
is defined as an OBF-generated interrupt that occurs during the process of sending a request message to the BMC 
and receiving the corresponding response. This occurs from the start of the write (request) phase of the message 
(issuing WRITE_START to the command register) through to the normal conclusion of the corresponding read 
(response) phase of the message. (The conclusion of the communications interval is normally identified by the 
interface going to IDLE_STATE). KCS communications interrupts are also encountered during the course of 
processing a GET_STATUS/ABORT control code. 


A KCS non-communication interrupt is defined as an OBF-generated interrupt that occurs when the BMC is not 
in the process of transferring message data or getting error status. This will typically be an interrupt that occurs 
while the interface is in the IDLE_STATE. 


There are several options in the BMC that can be enabled to cause KCS non-communication interrupts as 
described in the Set BMC Global Enables command, and Get Message Flags commands. These are the watchdog 
timer pre-timeout interrupt, event message buffer interrupt, receive message queue interrupt, and the OEM 
interrupts. Software can detect which of the standard interrupts are supported by attempting to enable them using 
the Set BMC Global Enables command and checking for an error completion code. 


9.13 Physical Interrupt Line Sharing 


A typical interrupt-driven implementation will assert a physical interrupt line when OBF is asserted. In order to 
allow a single interrupt line to serve for both communication and non-communication interrupts, the physical 
interrupt line must be automatically deasserted by the BMC whenever a communication phase begins, even if 
there is a pending non-communications interrupt to be serviced. This is necessary so the interrupt line can be used 
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for signaling communication interrupts . Once the communication operations have completed (return to idle 
phase) the controller must re-assert the interrupt line if the non-communications interrupt is still pending. 


9.14 Additional Specifications for the KCS interface 


This section lists additional specifications for the KCS interface. 


e The BMC must generate an OBF whenever it changes the status to ERROR_STATE. This will ensure that any 
transition to ERROR_STATE will cause the interrupt handler to run and catch the state. 


e The BMC generates an OBF upon changing the status to IDLE_STATE. An IPMI 1.5 implementation is 
allowed to share this interrupt with a pending KCS non-communication interrupt, or it elect to always generate a 
separate OBF interrupt for non-communications interrupts. 


e A BMC implementation that elects to always generate a separate non-communications interrupt must wait for 
the OBF interrupt that signals entering the IDLE_STATE to be cleared before it asserts an OBF interrupt for the 
non-communications interrupt. 


e IPMI v1.5 systems are allowed to generate a single OBF that covers both the last communications interrupt 
(when the BMC status goes to IDLE_STATE) and a pending non-communications interrupt. Le. it is not 
required to generate a separate OBF interrupt for the non-communications interrupt if a non-communications 
interrupt was pending at the time the BMC status goes to IDLE STATE. In order to support this, an IPMI v1.5 
KCS interface implementation must set SMS_ATN for all standard (IPMI defined) non-communication interrupt 
sources. 


e For IPMI v1.5, the BMC must set the SMS_ATN flag if any of the standard message flags become set. This 
includes Receive Message Available, Event Message Buffer Full (if the Event Message Buffer Full condition is 
intended to be handled by System Management Software), and Watchdog Timer pre-timeout flags, as listed in 
the Get Message Flags command. This is independent of whether the corresponding interrupt is enabled or not. 


e The BMC must change the status to ERROR_STATE on any condition where it aborts a command transfer in 
progress. For example, if the BMC had an OEM command that allowed the KCS interface to be asynchronously 
reset via IPMB, the KCS interface status should be put into the ERROR_STATE and OBF set, not 
IDLE_STATE, in order for software to be notified of the change. However, the BMC does not change the status 
to the ERROR_STATE, but to the IDLE_STATE, when the BMC executes the Get Status/Abort control code 
from SMS I/F, even if the Get Status/Abort control code is used to abort a transfer. 


e A cross-platform driver must be able to function without handling any of the OEM bits. Therefore, enabling 
SMS_ATN on OEM interrupts/states must not be enabled by default, but must be explicitly enabled either by 
the Set BMC Global Enables command or by an OEM-defined command. 


e The SMS ATN bit will remain set until all standard interrupt sources in the BMC have been cleared by the 
Clear Message Flags command, or by a corresponding command. For example, the Read Message command 
can automatically clear the Receive Message Queue interrupt if the command empties the queue. 


e AKCS interface implementation that allows its interrupt to be shared with other hardware must set SMS ATN 
whenever it generates a KCS interrupt. A system will typically report whether it allows an interrupt to be shared 
or not via resource usage configuration reporting structures such as those in ACPI. 


e OEM non-communications interrupts should be disabled by default. They must be returned to the disabled state 
whenever the controller or the system is powered up or reset. This is necessary to allow a generic driver to be 
used with the controller. A driver or system software must be explicitly required to enable vendor-specific non- 
communications interrupt sources in order for them to be used. OEM non-communications interrupt sources 
must not contribute to SMS_ATN when they are disabled. 


e The OEM 0, 1, and 2 flags that are returned by the Get Message Flags command may also cause the SMS_ATN 
flag to be set. A platform or system software must not enable these interrupts/flags unless there is a 
corresponding driver that can handle them. Otherwise, a generic cross-platform driver could get into a situation 
where it would never be able to clear SMS_ATN. 
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e It is recommended that any OEM generated non-communications interrupts cause at least one of the OEM flags 
in the Get Message Flags to become set. This will enable improving system efficiency by allowing a cross- 
platform driver to pass the value of the Get Message Flags to an OEM extension, saving the OEM extension 
software from having to issue an additional command to determine whether it has an anything to process. 


e It is recommended that an OEM that uses the OEM flags sets the SMS_ATN flag if one or more of the OEM 
flags (OEM 0, OEM 1, or OEM 2) becomes set, especially if those flags can be the source of a KCS non- 
communications interrupt. The driver can use SMS_ATN as the clue to execute the Get Message Flags 
command and pass the data along to an OEM extension routine. 


e OEM non-communications interrupts may elect to either share the IDLE STATE OBF interrupt with the non- 
communications interrupt OBF, or generate a separate non-communications OBF interrupt. If the OEM non- 
communications interrupt implementation shares the IDLE STATE OBF interrupt, the OEM non- 
communications interrupt must also set SMS_ATN. 


9.15 KCS Flow Diagrams 


The following flow diagrams have been updated from corresponding diagrams in the original IPMI v1.0, rev. 1.1 
specification. This information applies to the following flow diagrams: 


e Al system software wait loops should include error timeouts. For simplicity, such timeouts are not shown 
explicitly in the flow diagrams. A five-second timeout or greater is recommended. 


e The phase values represent state information that could be kept across different activations of an interrupt 
handler, and corresponding entry points. Based on the 'phase' the interrupt handler would branch to the 
corresponding point when an OBF interrupt occurred. The information may also be useful for error reporting 
and handling for both polled- and interrupt-driven drivers. Note that other state may need to be kept as well. For 
example, during the 'wr_data’ phase, the handler may also need to preserve a byte counter in order to track 
when the last byte of the write was to be sent. 


e The symbol of a circle with an arrow and the text ‘OBF’ inside the circle represents the points where the BMC 
would write a dummy data byte to the output buffer in order to create an OBF interrupt. The label above the 
circle indicates where an interrupt handler would branch to when the OBF interrupt occurs under in the 
corresponding phase. An interrupt handler would exit upon completing the step that occurs before where the 
OBF interrupt symbol points. 
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Figure 9-, KCS Interface SMS to BMC Write Transfer Flow Chart 
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Figure 9-, KCS Interface BMC to SMS Read Transfer Flow Chart 
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Figure 9-, Aborting KCS Transactions in-progress and/or Retrieving KCS Error Status 
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9.16 Write Processing Summary 


The following summarizes the main steps write transfer from system software to the BMC: 
e Issue a ‘WRITE START’ control code to the Command register to start the transaction. 
e Write data bytes (NetFn, Command, Data) to Data In. 


e Issue an ‘WRITE END’ control code then the last data byte to conclude the write transaction. 


9.17 Read Processing Summary 


The following summarizes the main steps for a read transfer from the BMC to system software: 
e Read Data Out when OBF set 
e Issue READ command to request additional bytes 


e IfREAD_STATE (after IBF = 0), repeat previous two steps. 


9.18 Error Processing Summary 


The following summarizes the main steps by which system software processes KCS Interface errors: 


e Issue a ‘GET STATUS/ABORT"” control code to the Command register. Wait for IBF=0. State should be 
WRITE_STATE. 


e If OBF=1, Clear OBF by reading Data_Out register. 

e Write 00h to data register, wait for IBF=0. State should now be READ STATE. 

e © Wait for OBF=1. Read status from Data Out 

e Conclude by writing READ to data register, wait for IBF=0. State should be IDLE. 
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9.19 Interrupting Messages in Progress 


If, during a message transfer, the system software wants to abort a message it can do so by the following methods: 


1. Place another “WRITE START” command into the Command Register (a WRITE START Control Code 
is always legal). The BMC then sets the state flags to “WRITE STATE” and sets its internal flags to 
indicate that the stream has been aborted. 


2. Senda “GET STATUS/ABORT” request. This is actually the same as #1 above but is explicitly stated to 
indicate that this command will cause the current packet to be aborted. This command allows a stream to be 
terminated and the state to be returned to IDLE without requiring a complete BMC request and response 
transfer. 


9.20 KCS Driver Design Recommendations 


A generic, cross-platform driver that supports the interrupt-driven KCS interface is not required to handle 
interrupts other than the interrupt signal used for IPMI message communication with the BMC. The message 
interrupt may be shared with other BMC interrupt sources, such as the watchdog timer pre-timeout interrupt, the 
event message buffer full interrupt, and OEM interrupts. 


A cross-platform driver should use the Get BMC Global Enables and Set BMC Global Enables commands in a 
‘read-modify-write’ manner to avoid modifying the settings of any OEM interrupts or flags. 


It is recommended that cross-platform driver software provide a ‘hook’ that allows OEM extension software to 
do additional processing of KCS non-communication interrupts. It is highly recommended that the driver 
execute the Get Message Flags command whenever SMS_ATN remains set after normal processing and 
provide the results to the OEM extension software. 


The driver cannot know the whether the pre-existing state of any OEM interrupts or flags is correct. Therefore, 
a driver that supports OEM extensions should allow for an OEM initialization routine that can configure the 
OEM flags/interrupts before KCS OBF-generated interrupts are enabled. 


It is recommended that cross-platform drivers or software make provision for BMC implementations that may 
miss generating interrupts on a command error condition by having a timeout that will activate the driver or 
software in case an expected interrupt is not received. 


A driver should be designed to allow for the possibility that an earlier BMC implementation does not set the 
SMS_ATN flag except when there is data in the Receive Message Queue. If the driver cannot determine 
whether SMS_ATN is supported for all enabled standard flags or not, it should issue a Get Message Flags 
command whenever it gets a KCS non-communication interrupt. 


A driver or system software can test for whether the Watchdog Timer pre-timeout and/or Event Message Buffer 
Full flags will cause SMS_ATN to become set. This is accomplished by disabling the associated interrupts (if 
enabled) and then causing a corresponding action that sets the flag. This is straightforward by using the 
watchdog timer commands in conjunction with the Set BMC Global Enables and Get Message Flags 
commands. 


For example, to test for the Event Message Buffer Full flag setting SMS_ATN, first check to see if the Event 
Message Buffer feature is implemented by attempting to enable the event message buffer using the Set and Get 
BMC Global Enables command. If the feature is not implemented, an error completion code will be returned. 
Next, disable event logging and use the watchdog timer to generate an SMS/OS ‘no action’ timeout event, then 
see if the SMS_ATN becomes set. If so, use the Get Message Flags command to verify that the Event Message 
Buffer Full flag is the only one set (in case an asynchronous message came in to the Receive Message Queue 
during the test.) The pre-timeout interrupt can be testing in a similar manner. 


It is possible (though not recommended) for a BMC implementation to include proprietary non- 
communication interrupt sources that do not set SMS_ATN. These sources must not be enabled by default. It 
is recommended that a generic cross-platform driver have provisions for OEM extensions that get called 
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whenever a non-communication interrupt occurs. It is recommended that the extension interface provides the 
last reading of the KCS flags so that an OEM extension can see the state of SMS_ATN. 


Software should be aware that IPMI v1.0 implementations were not required to set SMS_ATN for all non- 
communication interrupts. If a BMC implementation does not set SMS_ATN for all non-communication 
interrupts, it must generate a separate OBF interrupt for non-communication interrupts. A controller that does 
not set SMS_ATN for all non-communication interrupts is not allowed to use the same OBF interrupt to 
signal the both completion of communications and a non-communications interrupt. 


Regardless of whether the IDLE_STATE OBF interrupt is shared with a pending non-communications 
interrupt, software drivers must examine SMS_ATN after clearing OBF. If SMS_ATN is asserted the driver 
must process the non-communications interrupt sources. 


Intelligent Platform Management Interface Specification 


10. SMIC Interface 


This section provides the specifications of the SMIC (Server Management Interface Chip) interface. The SMIC 
interface is one of the physical interfaces specified for transferring IPMI messages between the system management 
software and the system’s primary management controller (BMC). 


The interface can be readily implemented using an external ASIC or standard programmable logic to provide a byte 
VO-mapped messaging interface to standard microcontrollers. 


The SMIC Interface is designed to support polled operation. Implementations can optionally provide an interrupt 
driven from the BUSY bit, but this must not prevent driver software from using the interface in a polled manner. 
This allows software to default to polled operation. It also allows software to use the KCS interface in a polled mode 
until it determines the type of interrupt support. Methods for assigning and enabling such an interrupt are outside the 
scope of this specification. 


The specification of the SMIC interface registers is given solely with respect to the ‘system software side’ view of 
the interface in system I/O space. 


The functional behavior of the management controller to support the SMIC registers is specified, but the physical 
implementation of the interface and the organization of the interface from the management controller side is 
implementation dependent and is beyond the scope of this specification. 


10.1 SMS Transfer Streams 


The SMIC interface is designed to be interruptible to allow the one physical interface to be shared by two types of 
system software: SMM (System Management Mode) software that runs from within an SMI Handler, and SMS 
(System Management Software) that runs under the OS. 


If an SMS transaction is interrupted, system management software will need to restart the Request/Response 
transaction it had in progress. 


To support this sharing, the interface provides mechanisms that allow system management software to detect that 
its use of the interface has been interrupted. The protocol for messaging between SMM and the BMC over the 
SMIC interface is implementation specific and not covered by this specification. 


10.2 SMIC Communication Register Overview 


The SMIC registers are mapped into system I/O space. This shared register space consists of three byte-wide 
registers: 


e Flags Register - provides flags for use in various defined operations 
e  Control/Status Register - accepts control codes and returns status codes 
e Data Register - provides a port for transactions that exchange message data 


Message contents are passed through the data register. This includes the fields of a message, such as the Network 
Function code, Command Byte, and any additional data required for the Request or Response message. 


The control register is loaded with control code values that are used for framing the message data (indicating 
message start, middle, and end) and for indicating message data transfer direction. 


Status codes are returned through the control/status register. A control code is required to initiate for each data 
byte transferred through the data register. 


The Flags register contains bits that indicate whether the controller has a message for system software, generated 
an SMI, or is ready for a transfer operation. The Flags register also contains a special BUSY bit, that is used by 
system software to initiate and handshake data byte transfers through the interface. 
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The SMIC interface is used as a polled interface. System software is always the “Master” for transfers between 
system software and the BMC. The BMC can signal that data is available via bits in the flags register, but data 
bytes will not be moved to or from the data register until the transaction is initiated by system software. 


10.3 SMIC/BMC Message Interface Registers 


The following figure illustrates the SMIC/BMC Interface Registers and register bits. These registers are located at 
three consecutive 8-bit port addresses in I/O space. 


The data, control/status, and flags registers appear at an I/O addresses OCA9h, OCAAh, and OCABh, 
respectively. 


Reserved bits should be written as ‘0’ and ignored during reads. Software should not assume that a reserved bit 
will return a constant value. 


Geer 10-, PAUC DME Heroes Registers, 
VO address 


a m ET SMS vd BUSY 
flags ATN | ATN base+2 
(ro) (ro) (ro) (r/w) 


data (r/w) base+0 


10.3.1 Flags Register 
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System software always initiates the SMIC transfers, regardless of direction. The management controller uses 
the SMS_ATN bit in the Flags register to indicate to system software that is has a message to be read. This bit 
will be set whenever data is present in the Receive Message Queue. 


Other bits in the Flags register are used to arbitrate access to the control/status and data registers between the 
BMC and system software. Bits 7::2 are read-only from the system bus and write-only from the BMC; these bits 
are used by the BMC as communication and status flags. Bit 0, the BUSY bit, is used as a semaphore for 
coordinating access to the control/status and data registers between the system bus and the BMC. The following 
table summarizes the functions of Flags Register bits. 
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Table 10-, SMIC Flags Register Bits 
Bi [Name [Description — 


7 RX DATA RDY Indicates that the BMC has data that can be delivered in response to a 
‘READ’ control code. RX DATA RDY must be ‘1’ before a control code that 
causes a data byte to be transferred (read) from the BMC into the data 
register can be issued. RX DATA RDY shall also be set to ‘1’ whenever a 
‘READY’ status code is returned. RX DATA RDY should be ignored when 
issuing control codes that do not cause a data byte to be read from the BMC. 

TX DATA RDY Indicates that the BMC is ready to accept a ‘WRITE’ control code and data. 
TX DATA RDY must be ‘1’ before a control code that causes data to be 
transferred (written) to the BMC from the data register can be issued. 
TX DATA RDY can be ignored when issuing control codes that do not 
cause a data ARE 2 98 Ye De MNRE to be written to the BMC. 
5 [Reserved — 


SMI ——E that the BMC has asserted the SMI signal and has internal ‘SMI 
event’ flags that are set. 


E? ATN Indicates that an Event Message has been received by the BMC and is ready 
to be read from the Event Message Buffer in the BMC. If SMIs are used, this 
flag may also set when an OEM message for the SMI Handler is available. 


Wa ATN Indicates that the BMC has messages that are ready to be read from the 
Receive Message Queue in the BMC. An implementation can use the 0-to-1 
transition of this bit to provide an interrupt. Clearing the Receive Message 
Queue clears this bit and clears ‘Receive Message Queue not empty’ as an 
interrupt source. 


7_[Resened | 


ae ee ee 

BUSY Provides the arbitration mechanism for SMIC mailbox register access. This 

bit is only set (1) from the system side and only cleared (0) by the BMC. The 

system side sets the BUSY bit whenever it wishes to send a control code 

(and data, if appropriate) to the BMC. The BMC acknowledges that it has 

accepted and acted on the control code (and performed the data byte 

transfer) by clearing the BUSY bit. An implementation can use the 1-to-0 

transition of BUSY to provide an interrupt. 


10.3.2 Control/Status Register 


The Control/Status register is the destination for control codes written from the system bus, and Status codes 
returned by the BMC. 


SMS transfers have a specific numeric range for control codes and status codes. This provides a ‘stream ID’ that 
allows the BMC to tell whether SMS or some other message stream issued a control code. This also allows 
system software to detect interruption by examining which the range of values for the most recent status code. 
The control and status codes used for SMS transactions are defined in the control code and status code tables in 
the sections following Section 10.9, SMIC Control and Status Code Ranges. 


10.3a Control and Status Codes 


Message transfer control and framing codes (control codes) are transferred via the Control/Status register 
while message content, such as command and data bytes, is transferred the Data register. control codes are 
unique to each transfer stream and defined transaction and for each phase (beginning, intermediate, and end) 
of a message. 


Status Codes confirm the message phasing, identify the active stream, and provide error status. 


When a message is transferred between system software and the BMC, each byte of the message that is 
passed through the data register is accompanied by a control code written to the Control/Status register. The 
BMC acknowledges reception of the control code and data byte by writing a corresponding Status Code to 
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the Control/Status register before clearing the BUSY bit. Note that Status Codes are returned for each 
transaction, regardless of whether a data byte is transferred or not. 


10.3.3 Data Register 


The message bytes for all requests (commands) and responses between system software and the BMC pass 
through the Data register. The data register must only be written or read from the system side when the BUSY 
bit is clear. 


Messages to the BMC contain the same types of message body fields as messages on the IPMB. This includes 
Network Function, Command byte, and Data fields. 


10.4 Performing a single SMIC/BMC Transaction 


The following steps describe how system software issues a control code to the BMC and transfers a data byte 
through the SMIC interface. 


1. 


System software polls the BUSY bit of the Flags register until it reads back as cleared (0) by the BMC. 
When the BUSY bit is 0, the BMC is ready to accept a new control code. System software is not 
allowed to access the Control/status or Data Registers when the BUSY bit is high. 


System software writes the control code to the Control/Status register. See Section 10.9, SMIC Control 
and Status Code Ranges and following, for control and status code specifications. 


If the transfer is a ‘Write’ transfer, and the control code is for 'WR NEXT” or ‘WR_END?’ operation, 

system software waits for the TX_DATA_RDY bit to be set become set. This indicates that the BMC 

is ready for the next write data byte. If the transfer is a ‘Read’ transfer, wait for the RX DATA RDY 

bit to be set. (The exception to this is the ‘GET STATUS” control code, which though it causes a data 
byte to be returned (the error code) does not require RX DATA RDY to be high first. 


If the transfer is a ‘Write’ transfer, system software loads the data to be written to the BMC into the 
Data register. 


System software then initiates the operation by setting the BUSY bit. Setting the BUSY bit causes the 
BMC to read the SMIC control code register and act on the control code. If the transfer is a Write 
transfer, the BMC reads the data from the data register at this time. If the transfer is a Read transfer, 
the BMC writes the data to the data register. The controller then returns a status code in the 
control/status register. data or an error code in the data register (as appropriate), and clears the BUSY 
bit. 


System software waits for the BUSY bit to clear, indicating the completion of the control code 
operation. 


System software reads the Control/Status register for the completion status of the transaction. If the 
operation was successful, the status code will reflect the next step in the transaction, or the successful 
completion of the transaction. If the operation was not successful, the status code will be set to 
‘READY’ and the data register will hold an error code. 


10.5 Performing a SMIC/BMC Message Transfer 


Multiple transactions are required to transfer a message between system software and the BMC. In this case, a 
message transfer refers to the sequence of steps required to transfer a series of data bytes to or from the BMC. 
One control code transaction is required for each message data byte transferred via the SMIC interface. 


A message transfer can be restarted at any time. Issuing an SMS WR START control code immediately aborts 
any message transfer in progress and begins a new write transfer. Issuing WRITE_START control codes does not 
require the RX DATA RDY or TX_DATA_RDY flags to be set. 
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The control code/status code sequences for the SMS-to-BMC transactions follows a “Transfer Start, Transfer 
Middle, Transfer End” pattern: 


Issue a ‘Start’ control code to start the transaction. Signifying ‘Transfer Start’ 


Issue ‘Next’ control codes to transfer the body of the data bytes. Signifying ‘Transfer Middle’. These 
are either “Write Next” or ‘Read_Next’ control codes, dependent on the transfer direction. 


Issue an ‘End’ control code to conclude the transaction and return the stream to the ‘Ready’ status. 
This signifies ‘Transfer End’ 


The following summarizes these steps: 


1. 


10.6 


If the transfer is a write transfer (system software to BMC), load the data register with the appropriate 
data and issue the ‘Write Start’ control code for the stream. There is no need to check 
TX_DATA_RDY. 


If the transfer is a read transfer (a data byte transfer from the BMC to system software) wait for the 
RX_DATA_RDY flag to become set, then issue the ‘Read Start’ control code for the stream. 


After each transaction, check the status code to see if the operation was successful. For write transfers, 
the status code will generally be a ‘Write Next’, indicating that the interface is ready to accept more 
data. For read transfers, the status code will typically be either a ‘Read Next’, indicating that there is 
more data to be read, or a ‘Read End’ indicating that the last byte of data was transferred. If the 
operation was aborted or an error occurred the transaction will need to be restarted from the beginning. 


Continue the transfer based on the status code. For read transfers, wait for the RX DATA RDY flag 
and perform read operations until a ‘Read End’ status code is encountered (or an abort). For write 
transfers, wait for the TX_DATA_RDY flag and perform write operations until you conclude the 
transfer with a ‘Write End’ control code. 


Issue any additional control codes to return the transfer stream to the ‘Ready’ condition (indicated by 
the ‘Ready’ status code). For read transfers from the SMM/SMS streams, this requires issuing a ‘Read 
End’. 


Interrupting Streams in Progress 


Any software that interrupts a transfer in progress and switches to another stream is responsible saving and 
restoring the status and data register values for the transaction that was in effect at the time of the interrupt. The 
interrupting routine must first wait for the BUSY bit to clear and then save the control/status and data register 
contents. Before exiting, the interrupting routine must wait for the BUSY bit to clear following its last transaction, 
then restore the control/status and data register values. The interrupting routine can then perform its transfer(s). 
After the interrupting routine concludes its last transaction, it must wait for BUSY to clear and restore the original 
control/status and data register contents before returning from the interrupt. 


The following summarizes the steps for an interrupting routine, e.g. an SMI Handler: 


1. 
2. 


Poll the BUSY bit until cleared by the BMC. 
Save the contents of the Control/Status and Data registers. 
Perform the desired message transfers. 


Wait for the BUSY bit to clear, then restore the Control/Status and Data register values that were saved 
in step 2, and return to the interrupted routine. If the interrupted routine has additional bytes to transfer, 
the succeeding control code will be ‘out-of-phase’ with the state expected by the BMC. The BMC will 
then return a ‘READY’ status code with an ‘Aborted’ return value. This indicates to the interrupted 
routine that it needs to restart the transaction. If the interrupt happened to occur between transfers, or 
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on the last transfer of a transaction, the Control/Status and Data registers will have the correct values 
and the interrupted routine will be able to start a new transaction. 


10.7 Stream Switching 


A stream switch occurs when the BMC receives a WR_START control code with a ‘stream ID’ that is different 
than the stream ID for the previous control code. This is the mechanism that SMS uses to restart an interrupted 
transaction. If a control code, other than WR_START is issued, and the stream does not match the stream ID for 
the previous control code, the BMC shall return a ‘READY’ status code with an ‘Aborted’ return value. 


10.8 DATA RDY Flag Handling 


The BMC shall set the TX DATA RDY whenever it is ready to accept a WR START”, "WR NEXT”, or 
"WR END” control code that transfers a data byte from the SMIC data register. Note that system software does 
not need to check for TX_DATA_RDY in order to issue a WR_START. 


The BMC shall set the RX DATA RDY flag whenever it has a data byte that is ready to be requested with a 
‘Read Start’, “Read Next’, or ‘Read End’ control code, or when it is prepared to return a ‘Ready’ status code. 


The BMC shall set the RX_DATA_RDY flag whenever it returns a ‘Ready’ status code to the 
stream. This includes when a stream is interrupted or when other errors occur during a transfer. 
This is to ensure that a routine that may be spinning on the RX_DATA_RDY bit will proceed and 
attempt its next transaction. 


The BMC shall only deassert (0) the RX DATA RDY or TX_DATA_RDY flags while BUSY is asserted (1). 
The BMC can assert the RX_DATA_RDY or TX_DATA_RDY flags any time that the associated conditions 
become true. 
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10.9 SMIC Control and Status Code Ranges 


Specific Control Code ranges are used to identify transactions using the SMS transfer stream. This allows the 
BMC to tell when the SMS stream is in use. Status Codes are returned by the BMC in the SMIC Control/Status 
register to reflect the completion status of a previously issued control code. Like the control codes, the Status 
Codes occupy a specific range for SMS transactions. Another set of control and status code ranges is reserved for 
OEM / SMI Handler. 


The presently defined ranges are: 
e 40h-5FhSMS (System Management Software) Transfer Stream Control Codes 
e COh-DFh SMS (System Management Software) Transfer Stream Status Codes 
e 60h-7Fh Available SMM (System Management Mode) / OEM Transfer Stream Control Codes 
e EOh-FFh Available SMM (System Management Mode) / OEM Transfer Stream Status Codes 


All unspecified codes are reserved. 
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10.10 SMIC SMS Stream Control Codes 


Table 10-, SMS Transfer Stream control codes 
Gode [Name [Description 


SMS STREAM CONTROL CODES 


40h CC_SMS_GET_STATUS | Get status related to the SMS (system mgt. software) transfer stream. An 
'SC SMS RDY' status code will be returned as the completion status for this 
control code, along with the last error code for the stream in the data register. 

4th CC_SMS_WR_START Write the first message byte of an SMS write transfer. This is also used to 
switch to the SMS stream. The SMIC data register must be loaded with the 
data byte to be written to the BMC. The non-error completion status for this 
control code will be an 'SC SMS WR START" status code. The data register 
Contents will remain unaltered if no error occurred. 


CC SMS WR NEXT Write a ‘middle’ message byte in an SMS write transfer. The SMIC data 
register must be loaded with the data byte to be written to the BMC. The user 
must wait for the TX DATA RDY-1 before issuing the control code. The non- 
error completion status for this control code will be an 'SC SMS WR NEXT" 
status code. The data register contents will also remain unaltered if no error 
occurred. 


CC_SMS_RD_START Get the first byte of a read transfer from the BMC. The user must wait for 
RX_DATA_RDY = 1 before issuing the control code. The non-error completion 
status for this control code will be an ‘SC_SMS_RD_START status code in 
the status register and the data byte in the data register. 


CC_SMS_RD_NEXT Get a ‘middle’ message byte for an SMS read transfer. The user must wait for 
RX_DATA_RDY = 1 before issuing the control code. The non-error completion 
status for this control code will be an ‘SC_SMS_RD_NEXT’ status code in the 
status register if there is more data to read or an GC SMS RD END! status 
code if the last byte was transferred, and the data byte in the data register. 


CC_SMS_RD_END Used to tell the BMC that the last byte of an SMS read transfer has been read 


CC SMS WR END Indicates the last message byte for an SMS write transfer. The SMIC data 
register must be loaded with the last data byte to be written to the BMC for the 
Current message. The user must wait for TX DATA RDY-1 before issuing 
this control code. The non-error completion status for this control code will be 
an 'SC SMS WR END status code with an error code of ‘00’ in the data 
register, indicating ‘Ok’. 


from the data register. It is not necessary to check the RX_DATA_RDY flag 
before performing this operation. The non-error completion status for this 
control code will be an 'SC SMS RDY status code with an error code of ‘00’ 
in the data register, indicating ‘OK’. 


TE 
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10.11 SMIC SMS Stream Status Codes 
Table 10-, SMS Transfer Stream Status Codes 
[Gode [Name I 


SMS STREAM STATUS CODES 


[coh [SC SMS RDY — | BMC is ready for next SMS transfer. An error code is returned in the data register: | SMS_RDY BMC is ready for next SMS transfer. An error code is returned in the data register: 
00 = NO ERROR 
01 = UNSPECIFIED ERROR / ABORTED 
02 = ILLEGAL or unexpected control code 
03 = NO RESPONSE - response timeout. This will occur if the BMC cannot supply 
a command response. 
04 = ILLEGAL command. The request message is not recognized as being a legal 
BMC request. 
05 = BUFFER FULL. Attempt to write too many bytes to the BMC. 


SC_SMS_WR_START | This status code indicates that the BMC has accepted first byte of a write transfer 
and is ready for the next transaction. 
C2h SC_SMS_WR_NEXT The BMC has accepted next data byte of the write transfer, and is ready for the 
next transaction. 


C3h SC_SMS_WR_END The BMC has accepted the byte as being the last byte of the write transfer and is 
ready for next SMS transfer. An error code is returned in the data register: 
00 = NO ERROR 
01 = ABORTED 
02 = ILLEGAL or unexpected control code 
03 = NO RESPONSE - response timeout. This will occur if the BMC cannot supply 
a command response. 
04 = ILLEGAL command. The request message is not recognized as being a legal 
BMC request. 
05 = BUFFER FULL. Last byte could not be accepted. 


C4h SC SMS RD START | BMC has accepted the start of an SMS stream read transfer. The first data byte of 
GN EE ts retumed nthe Pd 
C5h SC SMS RD NEXT The BMC acknowledges a CC SMS RD NEXT control code and is indicating that 

ENE there is more data to be read. The reguested data byte is in the data register. 

C6h SC_SMS_RD_END The BMC acknowledges a CC_SMS_RD_NEXT control code and is indicating that 
E there is no more data to be read. The last data byte is in the data register. 

C7h- | reserved reserved 

DFh 
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10.12 SMIC Messaging 


The SMIC message interface is essentially a ‘single master’ interface, where the ‘Master’ is the system software 
on the system side of the interface. System software can only write Request Messages to the BMC, and can only 
receive Response Messages from the BMC. 


This does not mean that the system software cannot receive downstream ‘requests’ from the IPMB, or even the 
BMC. Downstream requests can be ‘wrapped’ in a BMC Response Message. For example, a downstream request 
could be placed in the Receive Message Queue where the data is retrieved using the Get Message command. The 
Response Message would contain the downstream request data - which could then be extracted from the Response 
Message by system software. 


Since the SMIC interface is a ‘point-to-point’ connection, a ‘Requester’s ID’ is not required in a Request Message 
to identify which physical interface to return a message response to. Only SMIC Event Request messages include 
a Requester ID in the form of the Software ID field. 


10.13 SMIC/BMC LUNs 


LUN 00b is typically used for all messages to the BMC through the SMIC interface. LUNs 01b is reserved for 
Receive Message Queue use and should not be used for sending other commands to the BMC. Note that messages 
encapsulated in a Send Message command can use any LUN in the encapsulated portion. 


10.14 SMIC-BMC Request Message Format 


Request Messages are sent to the BMC from system software using a write transfer through the SMIC. The 
message bytes are organized according to the following format specification: 


Figure 10-, SMIC/BMC Request Message Format 
Byte 1 Byte 2 Byte 3:N 


NetFn/LUN 


Where: 

LUN Logical Unit Number. This is a sub-address that allows messages to be routed to different 
‘logical units’ that reside behind the same physical interface. The LUN field occupies the least 
significant two bits of the first message byte. 

NetFn Network Function code. This provides the first level of functional routing for messages received 
by the BMC via the SMIC interface. The NetFn field occupies the most significant six bits of 
the first message byte. 

Cmd Command code. This message byte specifies the operation that is to be executed under the 
specified Network Function. 

Data Zero or more bytes of data, as required by the given command. The general convention is to 


pass data LS-byte first, but check the individual command specifications to be sure. 
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10.15 BMC-SMIC Response Message Format 


Response Messages are read transfers from the BMC to system software via the SMIC. Note that the BMC only 
returns responses via the SMIC interface when Data needs to be returned. The message bytes are organized 
according to the following format specification: 


Figure 10-, SMIC/BMC Response Message Format 
Byte 1 Byte 2 Byte 3 Byte 4:N 


NetFn/LUN Completion Code 


Where: 
LUN Logical Unit Number. This is a return of the LUN that was passed in the Request 
Message. 
NetFn Network Function. This is a return of the NetFn code that was passed in the Request 
Message. 
Cmd Command. This is a return of the Cmd code that was passed in the Request Message. 


Completion Code The Completion Code indicates whether the request completed successfully or not. 


Data Zero or more bytes of data. The BMC always returns a response to acknowledge the 
request, regardless of whether data is returned or not. 


10.16 Logging Events from System Software via SMIC 


The SMIC interface can be used for sending Event Messages from system software to the BMC Event Receiver. 
The following figures show the format for SMIC Event Request and corresponding Event Response messages. 
Note that only Event Request Messages to the BMC via the SMIC interface have a Software ID field. This is so 
the Software ID can be saved in the logged event. 


Figure 10-, SMIC Event Request Message Format 


NetFn LUN Command Software ID (Gen ID), 7-bits 1 
(04h = Sensor/Event Request) (00b) (02h = Platform Event) (20h-2Fh = system sw) 


Sensor Type Event Type | Event Data) | Event Data2 | Event Data 3 


[1] Shading designates fields that are not stored in the event record. 


Figure 10-, SMIC Event Response Message Format 


NetFn Command Completion Code 
(05h = Sensor/Event Response) (02h = Platform Event) 
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11. Block Transfer (BT) Interface 


This section describes the Block Transfer (BT) Interface. The BT interface is one of the supported BMC to SMS 
system interfaces. The BT interface is specified for SMS or OEM Defined messages. Messaging between the BMC 
and an SMI Handler is not specified for this interface. 


The BT Interface is so named because an entire block of message data is buffered before the management controller 
is notified of available data. This is different from the SMIC and KCS interfaces, which are byte-transfer oriented. A 
BT Interface Capabilities command provides supplementary information about extended buffer sizes and other 
elements of the interface. 


The host side of the BT Interface is designed for interrupt or polled operation. Implementations can elect to provide 
a system interrupt from the assertion of the B2H ATN or SMS_ATN (BMC-to-Host attention or System 
Management Software attention) states. Note that implementing an interrupt must not preclude driver software from 
the using the interface in a polled manner. 


The BT Interface is designed for efficient interrupt operation via assertion of H2B_ATN by the host. 
Provision for operation in a polled mode is optional. 


Methods for assigning, enabling, and determining the system interrupt are outside the scope of this specification. 


The BT interface provides support for implementations that allow the submission and asynchronous completion of 
commands. 


11.1 BT Interface-BMC Request Message Format 


Request Messages are sent to the BMC from system software using a write transfer through the BT Interface. The 
message bytes are organized according to the following format specification: 


Figure 11-, BT Interface/BMC Request Message Format 
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5:N 


Where: 


Length This is not actually part of the message, but part of the framing for the BT Interface. This value 
is the 1-based count of message bytes following the length byte. The minimum length byte 
value for a command to the BMC would be 3 to cover the NetFn/LUN, Seg, and Cmd bytes. 


LUN Logical Unit Number. This is a sub-address that allows messages to be routed to different 
‘logical units’ that reside behind the same physical interface. The LUN field occupies the least 
significant two bits of the first message byte. 


NetFn Network Function code. This provides the first level of functional routing for messages received 
by the BMC via the BT Interface. The NetFn field occupies the most significant six bits of the 
first message byte. 


Seq Used for matching responses up with requests. The BT interface can support interleaved *multi- 
threaded’ communications. There can be multiple simultaneous outstanding requests from SMS 
with responses returned asynchronously (and in any order). The Requester (SMS) sets the value 
for this field. The Responder returns the value in the corresponding response. The Seq field is 
used in combination with the NetFn and Command fields to form a unique value. Le the same 
Seq value could be used in multiple outstanding requests, as long as the combinations of Seq 
value, NetFn, and Command were unique among the requests. 


Cmd Command code. This message byte specifies the operation that is to be executed under the 
specified Network Function. 
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Data Zero or more bytes of data, as required by the given command. The general convention is to 
pass data LS-byte first, but check the individual command specifications to be sure. 


11.2 BMC-BT Interface Response Message Format 


Response Messages are read transfers from the BMC to system software via the BT Interface. Note that with a 
few exceptions (e.g., Cold Reset command) the BMC always returns response to a request delivered via the BT 
interface in order to deliver the completion code, regardless of whether the response has data in the Data field. 
The message bytes are organized according to the following format specification: 


Figure 11-, BT Interface/BMC Response Message Format 
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5:N Byte 6:N 


Length NetFn/LUN Completion Code 
Where: 


Length This is not actually part of the message, but part of the framing for the BT Interface. 
This value is the 1-based count of message bytes following the length byte. The 
minimum length byte value for a response from the BMC would be 4 to cover the 
NetFn/LUN, Seq, Cmd, and Completion Code bytes. 


LUN Logical Unit Number. This is a return of the LUN that was passed in the Request 
Message. 


NetFn Network Function. This is a return of the NetFn code that was passed in the Request 
Message. 


Seq Used for matching responses up with requests. The BT interface can support 
interleaved ‘multi-threaded’ communications. There can be multiple simultaneous 
outstanding requests from SMS with responses returned asynchronously (and in any 
order). The Requester (SMS) sets the value for this field. The Responder returns the 
value in the corresponding response. The Seq field is used in combination with the 
NetFn and Command fields to form a unique value. Le the same Seq value could be 
used in multiple outstanding requests, as long as the combinations of Seq value, 
NetFn, and Command were unique among the requests. 


Cmd Command. This is a return of the Cmd code that was passed in the Request Message. 
Completion Code The Completion Code indicates whether the request completed successfully or not. 


Data Zero or more bytes of data. The BMC always returns a response to acknowledge the 
request, regardless of whether data is returned or not. 


11.3 Using the Seq Field 


System Management Software is expected to use the Seq field in the following manner. SMS maintains a list of 
the outstanding requests it has sent. This list holds the Seq, NetFn, and Command values that were used to send 
the request. There should be one entry in the list for each possible simultaneous outstanding request. When SMS 
generates a Seq value for a new request, it must ensure that the combination of Seq, Command, and NetFn values 
do not match any entries already in the outstanding request list. 


When a response is received from the BMC, SMS looks for a match between the Seq value, Command, and NetFn 
values in the response and an entry in the outstanding request list. If there is a match, the response is processed 
normally and the outstanding request list entry freed for a new request. If the response does not match, the 
response can be ignored or passed on to error tracking procedures. 
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11.4 Response Expiration Handling 


It is possible that conditions could occur where a response will not return for a given request. The Seq number 
associated with the request must be freed so it can be reused. To support this, SMS should implement a response 
expiration interval. 


The BMC must return a response within the specified response time seconds (per the Get BT Interface 
Capabilities command). If the response is not received in this time the corresponding entry in the SMS 
outstanding response list can be cleared. If retries are not recommended at the interface, a missing response 
constitutes an immediate error condition. If the interface recommends retries (per the Get BT Interface 
Capabilities command) SMS should retry the request up to the specified count. If the response is still not 
provided, an error has occurred. 


The typical BT Interface is expected to be fundamentally reliable without retries. The retry 
specification is to support possible commands within the controller that may occasionally exceed 
the Request-to-Response specification. An application can elect to implement retry counts that 
exceed the recommendation. 


The BMC must not return a given response once the corresponding Request-to-Response interval has passed. The 
BMC can ensure this by maintaining its own internal list of outstanding requests through the interface. The BMC 
could age and expire the entries in the list by expiring the entries at an interval that is somewhat shorter than the 
specified Request-to-Response interval. The BMC can define its own internal Seq value or tracking number for 
this purpose, or it could use the Seq, NetFn, and Command values in the same manner as SMS. 


11.5 Logging Events from System Software via BT Interface 


The BT Interface can be used for sending Event Messages from system software to the BMC Event Receiver. The 
following figures show the format for BT Interface Event Request and corresponding Event Response messages. 
Note that only Event Request Messages to the BMC via the BT Interface have a Software ID field. This is so the 
Software ID can be saved in the logged event. 


Figure 11-, BT Interface Event Request Message Format 


(04h = Sensor/Event Request) (00b) (02h = Platform Event) 7-bits 


Sensor Type Event Type | Event Data1 | Event Data2 | Event Data 3 


[ ] Shading designates fields that are not stored in the event record. 


Figure I 1-, BT Interface Event Response Message Format 


Length NetFn Seq Command Completion Code 
(05h = Sensor/Event Response) (02h = Platform Event) 


11.6 Host to BMC Interface 


The Host interface to the baseboard management controller (BMC) requires a block of 3 contiguous I/O locations on 
the system board. (A reference implementation fixes this at locations E4h:E6h. The interface circuitry will decode 
the lower 2 address lines, SA[1..0] ). A general-purpose chip select will be used to generate the select line for the 
interface, which is to reside in system I/O space. The I/O address offsets are defined as follows: 


Table 11-, BT Interface Registers 
Conse [Red LE 
| 0 | BT CTRL - control register 


BMC2HOST buffer HOST2BMC buffer 
BT_INTMASK - interrupt mask register 
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The two buffers must meet the specified maximum message size requirements for all protocols supported on the 
messaging channels implemented on the BMC. Implementations can choose to provide more depth optionally. The 
GET_BT_INTERFACE_CAPABILITIES command is used to query for the actual implementation buffer depth. 


The messaging protocol involves the host writing the command stream to the BT buffer, followed by setting a 
“attention” bit in the BT control register. This automatically generates an interrupt to the baseboard management 
controller (BMC). The BMC then reads command packet from the BT buffer, and clears the attention bit. After 
processing the command, the BMC then writes the response data to the host-bound buffer. Finally, the BMC sets an 
outbound attention bit and generates an interrupt to the host (the host may optionally poll the attention bits, and may 
enable/disable the interrupts via a MASK register). Refer to Section 11.7 for a walk-through of the sequence of 
operations used for transfers on the BT interface. 


There is no explicit requirement or recommendation for the hardware used to implement the interface. A discrete, 
custom, programmable array, or other implementation may be used at the discretion of the designer. As an example, 
some implementations have used a Xilinx* XC4003E Field Programmable Gate Array (FPGA) to implement the 
interface circuit because it provides on-chip user RAM that can be effectively used to implement the interface’s 
buffers. This implementation was able to provide 64-byte buffers. 


11.6.1 BT Host Interface Registers 
The Host BT interface provides an independent set of registers and interrupts to allow the Host driver to 
communicate with the baseboard management controller without conflicting with the O/S ACPI driver. 


11.6.2 BT BMC to Host Buffer (BMC2HOST) 


From the host side, this is a read-only buffer, which contains a command response stream from the embedded 
controller. The buffer must be a minimum of 64-bytes deep. This shares offset 1 of the I/O space with the 
HOST2BMC buffer. Hence I/O read cycles from the host CPU remove data from this buffer, whereas write cycles 
from the BMC load data into this buffer. 


11.6.3 BT Host to BMC Buffer (HOST2BMC) 


From the host side, this is a write-only buffer to which the host writes a command stream to the baseboard 
management controller. The buffer must be a minimum of 64-bytes deep. This shares offset 1 of the I/O space with 
the BMC2HOST buffer. Hence an I/O write cycles from the host CPU load data into this buffer, whereas read 
cycles from the BMC remove data from this buffer. 


11.6.4 BT Control Register (BT_CTRL) 


The host and the BMC use this register for various control functions defined below. 


Figure 11-, PI. cree BE poral 
Bl or H ae SEM ar ATN | B2H Am H2B m CLR | D PTR | CLR. we PTR 


Table 11-, BT_CTRL Register Bit Definitions 
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BIT 
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R/W* 


Write 1 to 
set bit; 
0 no effect 


R/C 
Write 1 to 
clear bit; 
0 no effect 


R/C 
Write 1 to 
clear bit: 
0 no effect 


R/S 
Write 1 to 
set bit; 

0 no effect 


R/S/C 
Write 1 to 
toggle 


Write 1 to 
clear bit; 
0 no effect 


R/S 
Write 1 to 
set bit; 

0 no effect 


R/S 
Write 1 to 
set bit; 

0 no effect 


R/C 
Write 1 to 
clear bit: 
0 no effect 


CLR_WR_PTR 


CLR_RD_PTR 


H2B ATN 
Reset State=0 


B2H_ATN 
Reset State=0 


SMS_ATN 
Reset State=0 


OEMO 
Reset State=0 


H BUSY 
Reset State=0 


FUNCTION 


Clear Write Pointer. The host writes a 1 to clear the write pointer to 
the BT HOST2BMC buffer; this bit is always read back as 0. 
Writing a 0 has no effect. Similarly, the BMC writes a 1 to clear the 
write pointer to the BT BMC2HOST buffer; this bit is always read 
back as 0. Writing a 0 has no effect. Clearing the pointer is defined 
as moving it to point to the start of the next valid buffer (typically 
the top of a single FIFO buffer). 

Clear Read Pointer. The host writes a 1 to clear the read pointer 
to the BT BMC2HOST buffer; this bit is always read back as 0. 
Writing a 0 has no effect. Similarly, the BMC writes a 1 to clear the 
read pointer to the BT HOST2BMC buffer; this bit is always read 
back as 0. Writing a 0 has no effect. Clearing the pointer is 
defined as moving it to point to the start of the next valid buffer 
(typically the top of a single FIFO buffer). 

Host to BMC Attention. When the host writes a 1 to this bit, an 
interrupt is generated to the baseboard management controller. 
The host should set this bit when it has completed writing a 
message stream to the HOST2BMC buffer. The baseboard 
management controller clears this bit after it has set the D BUSY 
bit. The host may poll the H2B_ATN bit to determine that the 
baseboard management controller has acknowledged the 
command. The capability to operate in a polled mode by the BMC 
is optional. 

BMC to Host Attention. The BMC sets this bit when it has 
completed writing a message response stream to the BMC2HOST 
buffer. The host may poll the B2H_ATN bit to determine that the 
baseboard management controller has finished writing a message 
response stream to the BMC2HOST buffer. After setting H_BUSY, 
the host should clear this bit to acknowledge receipt of the 
message response. This bit can be enabled to generate an 
interrupt to the host by setting the B2HI_EN bit in the INTMASK 
register. 

SMS Attention. The BMC sets this bit when it has detected and 
queued an SMS message that must be reported to the host. This 
allows the host to distinguish between command responses and 
SMS messages from the baseboard management controller. This 
bit can be enabled to generate an interrupt to the host by a host 
set of the B2HI_EN bit in the INTMASK register. The host clears 
this bit by writing a 1 to it. 

Reserved for definition by platform. Generic IPMI software must 
write this bit as 0, and ignore the value on read. The OEMO bit 
should be able to generate an interrupt to the BMC when written by 
the host but is not required (polled mode is acceptable). Typical 
usage is a “heartbeat” mechanism from/to the host; the host sets 
OEMO to interrupt the BMC and then polls this bit to be cleared 
(BMC is alive and responded to the interrupt). The BMC FW 
completes the acknowledge cycle by clearing OEMO upon receipt 
of the interrupt (host is alive). 

Host Busy. This bit is set/cleared by the Host to indicate that it is 
busy processing response/event data from the BMC or cannot 
accept response/event data at this time. It is set to 1 if the host 
writes a 1 when H_BUSY=0, cleared if the host writes a 1 when 
H_BUSY=1; there is no effect if the host writes a 0 to this bit 
(toggle implementation). The BMC will need to verify that this bit is 
cleared before sending a response or event message. 
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R/W* R/W* FUNCTION 


Host 


8 Baseboard Management Controller Busy. This bit is set/cleared 
Reset State=1 by the BMC to indicate that it is busy processing command/request 
to toggle data from the Host or cannot accept command/request data at this 


time. It is set to 1 if the BMC writes 1 when B_BUSY=0, cleared if 
the BMC writes 1 when B BUSY-1; there is no effect if the BMC 
writes 0 to this bit (toggle implementation). . The initial state of 
this bit should be set to 1 so that the BMC side driver can initialize 
and prepare to accept Host traffic before the Host attempts to use 
it the first time. 


* R=read; W=write; S=set; C=clear 
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11.6.5 BT Interrupt Mask Register (INTMASK) 


This register is used by the host to control which interrupts can be generated by the baseboard management 
controller. 


Figure 11-, BT INTMASK Register format 
7 6 5 4 3 2 1 0 
BMC_HWRST OEMS OEM2 | OEM1 | B2HIRQ | B2H IRQ EN 


Table 11- BT INTMASK Register Bit Definitions 
[Br [RW [NAME FONGWON SSSSOS—S—SSSSS.CCC‘“‘C#WTTCTC(‘*d 


RW | B2H_IRQ_EN | BMC to HOST Interrupt Enable. The interrupt is generated by the BMC-BT 
interface if B2H IRQ EN is set (1) and either the B2H_ATN or EVT ATN bits are 
set by the BMC. 


1 RW | B2H IRQ BMC to HOST Interrupt Active. This bit reflects the state of the interrupt line to the 
host, and therefore can only become set (1) if by B2H IRQ EN is set and the 
interrupt condition has occurred. 

On a read: 0 = interrupt to host not active; 1 = interrupt to host active 

On a write: 0 = no effect; 1 = clear interrupt (this is the source of the INT, and is 
immediately cleared by the O/S driver). This only clears the interrupt for the 
system interface. Other interrupts may require clearing flags internal to the BMC. 
If bit is 0, then a rising edge on B2H_ATN or EVT_ATN sets this to 1. If already 1, 
then no affect. 


Generic IPMI software must write this bit as 0, and ignore the value on read. 
Generic IPMI software must write this bit as 0, and ignore the value on read. 
Generic IPMI software must write this bit as 0, and ignore the value on read. 


Reserved for future definition by IPMI. Write as 0, ignore value on read. 


DAN | BMC_HWRST | Host to Baseboard Management Controller Reset. (OPTIONAL) 
de Always read back as zero. Writing a 1 to this bit will cause a hardware reset of the 
BMC. This is non-sticky; writing zero has no effect. This bit, if provided, is 


intended for to be used for error recovery by the host if loss of communication with 
the BMC occurs. 


| 6 | 
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11.7 Communication Protocol 


In the context of the BT Interface, the term Write Transfer refers to the Host writing data to the BMC, while Read 
Transfer refers to the Host reading data from the BMC. 


If the interface implementation supports multithreaded operation, the interface driver should always be looking for 
the B2H. ATN or EVT_ATN condition. In an interrupt driven implementation, this means the interrupt handler 
should always check for responses or asynchronous requests. In a polled implementation, the driver should 
periodically poll the state of these bits. 


Table I 1-, å Bd Write Transfer 


Start Enable host interface (Clear 
B BUSY) 


“Command” | Wait for B BUSY clear (BMC Wait for H2B_ATN 
(Write ready to accept a pale & (indicating data has been 
Transfer) H2B_ATN clear (signifying loaded into HOST2BMC 
acknowledge of previous buffer) 
command) 


Write 1 to CLR_WR_ PTR bit in 
BT_CNTRL (reset pointer to start 
of buffer) 


| bytes 1 to n of command 
(request) to HOST2BMC buffer 


Lë H2B ATN attention (tell BMC 
that write data is available) 


Set B_BUSY (indicating 
BMC is preparing to transfer 
data from the HOST2BMC 
buffer) 


— Clear H2B_ATN (the ACK) PIE EE 
Read HOST2BMC buffer | 0 | 0 | 


— NE B BUSY (indicating 
BMC is done transferring 
re 


Process command 
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Table 11-, BT Interface Read Transfer 


Operation BMC H2B_ B2H_ B_ BUSY H_BUSY 
ATN ATN 


“Response” | Wait for B2H ATN attention to be set Waits for H_BUSY to 
(Read (or wait for interrupt from BMC), be cleared 
Transfer) signaling BMC has data available for 


Write bytes 1 to n of 
response to 
BMC2HOST buffer 


Set B2H ATN 
(indicating BMC has 
put data in BMC2HOST 


Set H BUSY (indicating Host is in Wait for B2H ATN 
process of reading data from the clear (ACK of BMC 
interface) EET message 


| | Clear B2H ATN 


Write 1 to CLR RD PTR bit in 

BT CTRL 

Read bytes 1 to n of response phase 

from BMC2HOST buffer 

Clear H BUSY (indicating Host has 

completed reading data from the 
buffer) 


11.8 Host and BMC Busy States 


The host and BMC can set H BUSY and B_BUSY, respectively, as necessary to indicate they are not able to accept 
response/event or command data from the BMC or host, respectively for any reason. This allows for asynchronous 
housekeeping functions that might take an extended period of time (seconds or minutes) to be accomplished ma 
controlled manner and minimize the chance of getting out of synchronization - which might occur if the host or 
BMC "timed out" and assumed the other side was hung or not responding. 


11.9 Host Command Power-On/Reset States 


The BMC sets B_BUSY to 1 whenever it is initializing from a cold reset and following BMC power up. The 
interface will initialize with H BUSY, H2B_ATN, and B2H ATN set to 0 (reset state = 0). 
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12. SMBus System Interface (SSIF) 


The SMBus System Interface (SSIF) defines a SMBus-based system interface to the BMC. Unlike the other system 
interface definitions (e.g. KCS), SSIF does not specify a set of registers that is I/O or memory mapped into the host 
processor’s space. SSIF assumes the existence of a SMBus host controller in the system. The host-side register 
interface for SMBus host controllers is not standardized. Therefore, in order for system software to utilize this 
interface, a host controller-specific driver for the given operating system is required. 


SSIF encapsulates IPMI messages and transfers them between the host controller and BMC using the SMBus “Write 
Block” and “Read Block” protocols. With SSIF, the BMC is always accessed as a slave device on SMBus. The host 
controller masters the to write data to the BMC. When the BMC has data for the host, it asserts the SMB Alert to the 
host controller to signal that data is available. Software then directs the host controller to master the bus and perform 
a SMBus Read Block transaction to ‘pull’ the data from the BMC. 


Thus, the SMBus System Interface requires that that host controller support the SMBus “SMBAlert” signal. This 
signal is used as an interrupt to the host controller that indicates that the BMC has data available that is ready to be 
retrieved. SSIF also allows the BMC to be polled for data. 


A standard SMBus transaction is limited to transferring 32 data bytes. Some IPMI messages can take more than 32 
bytes. Therefore, the SSIF definition includes optional support for using more than one SMBus transaction to move 
data to and from the BMC in order to support IPMI messages that are longer than 32 bytes. 


The SSIF can optionally use the SMBus PEC (Packet Error Check) for data integrity. This is an 8-bit CRC on the 
SMBus transaction data. It is highly recommended that PEC be used in implementations where there may be 
electrical noise or where there may be other masters on the bus besides the SMBus host controller. PEC should be 
considered mandatory in any implementation where there could be devices that are “hot-plugged” or removed from 
the bus during SMBus transactions with the BMC. 


The SSIF uses two types of transactions for read and write operations, “single-part” and “multi-part”. Single part 
transactions are used when the entire IPMI message content can fit within the 32-byte maximum data portion of and 
SMBus Write- or Read-Block protocol transfer. Multi-part transactions are used when more than 32-bytes of IPMI 
message data need to be transferred across the system interface. 


12.1 Single Threaded Interface 


Like the KCS interface, the SSIF Interface is only specified as a ‘Single Threaded Interface’ for standard IPMI 
commands. That is, the BMC implementation is not expected to process more than one IPMI request at a time. 
While an implementation is allowed to have a degree of ‘command queuing’, for standard IPMI messages the SSIF 
lacks a ‘Seq’ field that software can use to match up particular instances of requests with responses. 


It is possible that a driver or software that issues a request (writes to the BMC) before the response for a previous 
command has been returned could get the response for the earlier command before getting the response to the 
present request, or possibly will only get one of the expected responses. Therefore, generic management software or 
drivers for SSIF should take care to avoid issuing new requests before prior requests have been completed, and 
software should always check fields in the response (e.g. NetFn/LUN and Command) to verify a given response 
matches up with a request. 


12.2 Single-part Write 


The Single-part write is a SMBus transaction that can transfer IPMI messages up to 32 bytes in length. The 
following table shows the format of this transaction. The values in parentheses indicate the number of bits for the 
particular field when the given field is not 8-bits. Only the address and data portions of the SMBus transactions are 
shown. SMBus START and STOP conditions and ACK/NACK bits are left out for simplification. The length field 
provides the count of data bytes of IPMI message content, up to 32 bytes. [PEC] indicates the optional presence of 
an SMBus PEC (packet error code) byte. This byte is NOT included in the byte count provided in the length field. 
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Table 12-, BMC Single-part Write 


Slave Address | R/W=0 | SMBus CMD | Length | NetFn | LUN 
(7) | fi) = 02h (6) | (2) 
IPMI CMD | IPMI Data | [PEC] 
(0 or more 
bytes) 


12.3 Multi-part Write 


A multi-part write is used when more than 32-bytes of IPMI message data need to be written to the BMC. This 
requires two or more SMBus Write-Block transactions, consisting of either a “Start” transaction followed by an 
“End” transaction, or a Start transaction, followed by one or more “Middle” transactions, and then an End 
transaction. 


The first part of the IPMI message is written using the Start transaction. Since Multi-part writes are for the purpose 
of transferring IPMI message data that, the Start transaction must always move 32-bytes of data; therefore the value 
of the length byte for the Start transaction is always 20h. 


The combination of a Start transaction followed by an End transaction can transfer up to 63 bytes of IPMI message. 
The Middle transaction is available when there is a need to transfer an IPMI message of greater than 63 bytes. As of 
this writing, there are no standard IPMI messages to the BMC that are longer than 63 bytes. Therefore, the ‘middle’ 
transaction is defined solely as needed by any OEM/group network functions (network function codes 2Ch:3Fh) in 
the particular BMC implementation. 


There is no specified limit to the number of ‘middle’ transactions that can occur in a transfer. As many ‘middle’ 
transactions as needed can be used to move the desired amount of data. Note, however, that since the interface is 
‘single threaded’ normal IPMI messaging will be unavailable until such transfers have completed. Note, however, 
that the maximum message size returned by the Get SSIF Interface Capabilities command is 255 bytes. 


It is required that all multi-part write transfers end with an “End” transaction. Middle transactions must move 32- 
bytes of data, therefore the value of the length byte for Middle transactions is always 20h. 


The End transaction is used for the last portion of message data that is written to the BMC. It indicates to the BMC 
that the message data transfer has completed and the BMC can process the message. The number of message data 
bytes in the End transaction can range from I to 32 bytes. 


Note that the SMBus specification does not allow the length (byte count) in the Write-Block protocol to be zero. 
Therefore, it is illegal to have the last Middle transaction in the sequence carry 32-bytes and have a length of ‘0’ in 
the End transaction. Software that uses the Middle transaction should take care to correctly handle the cases where 
the number of IPMI message bytes is an exact multiple of 32. 


12.3.1 Error conditions for Multi-part Writes 

It is possible that out-of-order operations may occur in the course of restarting systems or loading and unloading 
software. For example, the BMC could have just received a Middle transaction when a system restart cause the next 
operation to be a Start transaction. 
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received data that is received until the next Start transaction is received. 


Table 12-, BMC Multi-part Write Start 


Slave Address | R/W=0 | SMBus CMD | Length | NetFn i LUN 

(7) OI = 06h =20h (6) | (2) 
IPMI CMD IPMI Data [PEC] 

Table 12-, BMC Multi-part Write Middle 
Slave Address | R/W=0 | SMBus CMD | Length IPMI [PEC] 
(7) (1) = 07h =20h | Data 
Table 12-, BMC Multi-part Write End 
Slave Address | RW=0 | SMBus CMD | Length | IPMI Data | [PEC] 
(7) (1) = 07h 


12.4 Single-part Read Transaction 


The following table illustrates the format of a SMBus Read Block protocol for a Single-part Read transaction for 
SSIF. This transaction is primarily used for retrieving IPMI response data from the BMC. 


Table 12-, BMC Single-part Read 


Slave Address | RW=0 | SMBus CMD | Slave Address | R/W=1 | Length | NetFn | LUN 
(7) (1) = 03h (7) (1) (6) (2) 
IPMI CMD | Completion | IPMI Data | [PEC] 
Code* 


* = present in standard IPMI response messages 


12.5 Multi-part Read Transactions 


The following table illustrates the format of a SMBus Read Block protocols for Multi-part Read transactions for 
SSIF. There are four different transactions that can be used: Multi-part Read Start, Multi-part Read Middle, Multi- 
part Read Retry, and Multi-part Read End. 


The Read Start and Read End transactions are used together when 33 to 61 bytes of IPMI message data must be read 
from the BMC. The Read Start transfers the first 30 bytes of IPMI message data, the Read End transfers the 
remaining 3 to 31 bytes. (The Read Start uses a special pattern of OOh,O1h as the first two SMBus data bytes in the 
Read Block. Since the Read Block can carry a maximum of 32 read data bytes, the Read Start carries 30 bytes of 
IPMI message data. The Read End transaction includes a 1-byte constant “FFh” as the first SMBus data byte in the 
Read Block. Therefore, the Read Middle transaction can carry up to 31 bytes of IPMI message data. ) 


If more than 61 bytes must be read, one or more Read Middle transactions are also used. 


The Read Middle includes a 1-byte Block Number field as the first byte of SMBus data in the Read Block. Thus, 
each Read Middle transaction can carry up to 31 bytes of IPMI message data. 
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The Multi-part Read Retry is used to retry ‘middle’ blocks of data in a multi-part read transaction that uses Read 
Middle transactions. This is described in more detail below. 

The following tables illustrate the SMBus protocol formats for the multi-part read transactions. All multi-part read 


transactions follow the SMBus Read Block protocol, with the exception of the Multi-part Read Retry transaction 
which uses the Write Block protocol. 


Table 12-, BMC Multi-part Read Start 


Slave Address | RW =0 | SMBus CMD | Slave Address | 1 | Length | 00h | 01h 
(7) OI = 03h (7) | 
NetFn | LUN IPMICMD | Completion IPMI Data [PEC] 
(6) | (2) Code" 
Table 12-, BMC Multi-part Read Middle 
Slave Address | RW =0 | SMBus CMD | Slave Address i 1 | Length | Block 
(7) |. Di = 09h (7) number 
IPMI Data | [PEC] 


Where: block number is a number that is incremented, starting with 0, for each new block of message data returned 
using the Middle transaction. Block Number FFh is reserved for the Read End transaction. 


The multi-part read retry transaction is a Write-Block transaction that tells the BMC to return the given middle 
Block Number on the next multi-part read Middle transaction. This SMBus CMD is only required when multi-part 
read Middle transactions are implemented. 


Table 12-, BMC Multi-part Read Retry 
Slave Address | R/W=0 | SMBus CMD | Length 
(7) i (1) = 0Ah =1 
IPMI Data 


Block 
number 


[PEC] 


The multi-part read End transaction is a Read-Block transaction that concludes a multi-part read operation. 


Table 12-, BMC Multi-part Read End 


(7) 


Slave Address | 


RAN 0 
(1) 


SMBus CMD 
= 09h 


Slave Address | 
(7) 


1 


Length 


FFh 


IPMI Data 


[PEC] 


12.6 Retention of Output Data 


A BMC that implements PEC must retain previous output message data until the occurrence of a valid Write Start 
transaction, at which time the output message data is cleared. This behavior is needed to better support PEC. If the 
BMC automatically discarded data as it was read out, there might be no way to recover the message data if the PEC 
indicated the data was corrupted. However, with this provision, system software can retry the read transaction that 
had the error. 


The BMC will return the retained data if the Single- and Multi-part Read Start transactions are retried prior to the 
next valid write Start transaction. To re-read a given block of Middle data in a multi-part read, the block number 
must first be written to the BMC using the Multi-part Read Retry transaction. The next Multi-part Read Middle 
transaction will then return that block number, and any subsequent Multi-part Read Middle transactions will 
increment the block number and return following blocks. 
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12.7 SMBAlert Signal Handling 


The SMBAlert signal is automatically cleared by the BMC the first time a Single-part Read Start or multi-part Read 
Start is used to read a given set of data. SMBAlert will not be asserted by the BMC again until a new instance of 
data or status is available. 


A BMC is allowed to implement OEM functions that can assert SMBAlert. However, since such functions could 
interfere with the operation of a generic driver for the system interface, they must require being enabled by an OS- 
resident driver or software that is explicitly aware of those features. Furthermore, non-SSIF features that assert 
SMBAlert from the BMC must automatically become disabled prior to OS-load if the system is restarted (warm or 
cold reset). 


A BMC that supports SMBAlert being disabled will start up with SMBAlert disabled by default. A driver will need 
to explicitly enable SMBAlert. The BMC will return SMBAlert to the disabled state on system power-up and resets. 


12.7.1 Enabling/disabling SSIF SMBAlert 


The “Enable Receive Message Queue Full Interrupt” bit in the Set Global Enables command is used to 
enable/disable SMBAlert. Note that an implementation is allowed to have SMBAlert always enabled, however it is 
highly recommended that enable/disable control be implemented. 


12.8 Polling for output data 


If SMBAlert is disabled, software can poll for output data by issuing Read Start transactions until data is returned. If 
there is no data available, the BMC will NACK the read portion of the SMBus transfer. 


12.9 SMBus NACKs and Error Recovery 


The BMC can NACK the SMBus host controller if it is not ready to accept a new transaction. This could occur if 
write transactions follow too closely together, for example. (See Section 12.17,SSIF Timing) Typically, this will be 
exhibited by the BMC NACK ing its slave address. In some cases the BMC may NACK a SMBus data byte that is 
being written to it. This can occur if software attempts to write more data bytes to the BMC than it can handle (for 
example, in a multi-part write), or if some internal state change caused the BMC to need to reset its internal 
operation. 


If the BMC NACKs a single part transaction, software can simply retry it. If a ‘middle’ or ‘end’ transaction is 
NACK’d, software should not retry the particular but should restart the multi-part read or write from the beginning 
Start transaction for the transfer. 


12.10 PEC Handling 


[SMBus] allows a slave that receives a PEC to check the PEC and NACK the byte that carried the PEC value if the 
PEC is incorrect. Accomplishing this may require special hardware in order to generate the NACK without 
significant SMBus clock stretching. In order to avoid this requirement, a BMC implementation is allowed to always 
ACK the PEC. A BMC that receives an invalid PEC shall drop the data for the write transaction and any further 
transactions (read or write) until the next valid read or write Start transaction is received. 


A BMC that implements PEC will automatically start using PEC in read transactions after it receives any SSIF 
single-part write or multi-part write Start transaction that includes a valid PEC. The BMC shall cease using PEC in 
read transactions after it receives any SSIF single-part write or multi-part write Start transaction that does not 
include a PEC byte. (A BMC detects PEC by noting that it has received one more byte in the SMBus Write-Block 
transaction than was indicated by the length byte. If this occurs, it assumes that the additional byte was the PEC byte 
and then checks it for validity.) 
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12.11 SMBus Timeout and Hang Handling 


[SMBUS] provides an option for devices to drop off the bus and go back to waiting for the SMBus START 
condition if the SMBus clock is held low for greater than 25 milliseconds. There is no requirement for BMCs to 
implement this option. 


Per [SMBUS] the BMC must synch up to a SMBus START or STOP condition, regardless of which SMBus clock 
the condition occurs on. In order for a master to place a START or STOP condition on the bus, there must be no 
other party driving the SMBus data line low during the SMBus clock. It is possible on SMBus that a missed clock or 
incorrectly terminated transfer could leave a slave device that is being read in the state where it is outputting a ‘0’ 
data bit on the bus, waiting for the master to continue to clock the bus for the next bit(s). In this condition, the bus is 
in a state where START and STOP conditions cannot be generated by the master because the slave is holding the 
data line low. 


The BMC must allow the bus master to resynch the bus by allowing the master to clock the BMC until the master 
can issue a START or STOP condition. This means a that a BMC should ‘drop off the bus’ and let its data and clock 
lines go high (un-driven) if it gets clocked for returning more data than it has available. 


12.12 Discovering SSIF 


The recommended SMBus slave address for the SSIF to the BMC is address 20h (0010_000x binary). The SSIF 
Interface can be located at alternative addresses depending on the implementation. Note the slave address of the 
SSIF is not the same thing as the slave address of the BMC that is used for IPMB and IPMI Message use. For 
example, the slave address of the BMC on IPMB, and the slave address used with the Get Message command is 
required to be 20h regardless of the address used for the BMC on the SSIF Interface. An Intel architecture 
compatible system implementation that supports SMBIOS must include an SMBIOS “Type 38” record to support 
system management software discovery of the existence and slave address of the SSIF (see Appendix C1 - Locating 
IPMI System Interfaces via SM BIOS Tables). 


In addition, systems that support ACPI should also provide an SPMI table for the interface (see 
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Appendix C3 - Locating IPMI System Interfaces with ACPI). 


12.13 SSIF Support Requirements for IPMI v1.5-only BMCs 


The SSIF can be used with BMCs that implement just IPMI v1.5 commands. If the BMC uses SSIF and reports 
itself as an IPMI v1.5 BMC, then only the single-part write and single-part read transactions are required to be 
supported. 


Note that since single-part transactions only support IPMI messages up to 32 bytes, it limits the ability to transfer 
full-sized IPMI messages between the System Interface and other channels, such as IPMB. This is because 
transferring a message to another channel requires the message to be encapsulated in the data portion of a Send 
Message, Master Write-Read, or Get Message command. For example, the size of the response message for 
retrieving a full-size (32-byte) IPMB message using the Get Message command is 36 bytes. The largest IPMB 
message that could be obtained using Get Message with a single-part read would thus be limited be 28 bytes rather 
than 32. This can potentially cause problems with accessing satellite controllers on IPMB. 


It is highly recommended that multi-part writes and reads are implemented if SSIF is retro-fitted to an IPMI v1.5 
implementation, as described for IPMI v2.0 implementations, below. 


12.14 SSIF Support Requirements for IPMI v2.0 & Later BMCs 


Ifa BMC reports itself as conformant with IPMI v2.0 (or later), then the BMC must support multi-part writes and 
reads for IPMI messages if the BMC supports messaging between system software and other channels (e.g. 
implements serial or LAN channels, IPMB or PCI SMBus, etc.). This is because such messaging requires the ability 
to transfer IPMI message that are >32 bytes in order to fully support messages to another channel. 


The IPMB and PCI SMBus channels also need to support the Master Write-Read command as an alternative 
mechanism for delivering IPMI messages to their respective busses, and, in addition, it is recommended that PCI 
SMBus supports using the Master Write-Read command for performing full-size SMBus protocol operations. 


The following items are required of SSIF implementations on IPMI v2.0 or later BMCs: 


e Ifthe BMC implements any channels other than the system interface, it must implement multi-part writes 
and reads to enable accepting a 40 byte IPMI input message size, minimum, and support a 38 byte IPMI 
output message size, minimum. See Table 6-9, IPMI Message and IPMB / Private Bus Transaction Size 
Requirements and refer to Appendix D, Message Size Requirements for more information. 


e In addition, if the PCI SMBus is supported, the SSIF must support using the Master Write-Read command 
to execute all SMBus protocols (with and without PEC) on the target bus, including full-size SMBus Write- 
Block, Read-Block, and Block Write-Read Process Call. 


12.15 Summary of SMBus Commands Values for SSIF 


The following table summarizes the allocation of SMBus commands for SSIF. Note that there are command values 
that are reserved for future definition by the IPMI specifications. 
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Table 12-, Summary of SMBus Commands for SSIF 


SMBus 
Operation CMD Protocol 
BMC Single-part Write 02h Write Block 
BMC Multi-part Write 
Start - first part 06h Write Block 
Middle part(s) if any 07h Write Block 
End - last part 08h Write Block 
BMC Single-part Read 03h Read Block 
BMC Multi-part Read 
Start - first part 03h Read Block, first two data bytes after length = [0x01 ,0x00] 
Middle part(s) if any 09h Read Block, first data byte after length = 0x00 
End - last part 09h Read Block, first data byte after length = 0x01 
Retry OAh Write Block, first data byte after length = block number 
Reserved OBh-17h | Reserved. (Reserved CMD values apply to any SMBus 
protocol that uses a CMD byte.) 
OEM 00h,01h | Available for OEM use 
All other 


12.16 SSIF IPMI Commands 


The following sections list the IPMI commands used with the SSIF. See Table 22-, IPMI Messaging Support 
Commands for Optional/Mandatory usage of this command with SSIF. 


Table 12-, SSIF Commands 


Section 
Command Defined 
Get System Interface Capabilities 22.9 | 


12.17 SSIF Timing 


The following table lists the recommended timing specifications on SMBus for a BMC implementing the SSIF. Note 
that this timing can be dependent on the performance of the SMBus host controller used in the system. 
Specifications are given for a SMBus operating at 100 kbps. 


Table 12-, SSIF Timing Specifications 


Internal Timing Specifications — | | min | max | 

| Overall Message Duration TA > Lan | S O 

| Time-out waiting for bus free LI ons | - 1 | 

| Time-out waiting for a response, internal | T3 | 60ms" | Teman | o 

| Time between Event Message Requests | T4| 5ms | - | 

Request-to-Response time T5 EN T6max- | This interval is measured from the end of the 
Timax- | request transmission through the end of response 
3ms"! | transmission. (SMBus STOP to SMBus STOP) 


Number of Request retries (el JE recommended 


Time between Request retries [Te | om | 250ms | i 
Number of Event Message Request retes |C2 | 3 | 10 | 


spec 


SM Bus Clock Low hold T8 | per SMBus 3 ms recommended 
spec The BMC should avoid stretching the clock more 
than 3ms at a time. The BMC must tolerate the 
clock being stretched up to the maximum value 
specified by the SMBus specification. 
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Notes: 


1: 


Unless otherwise specified, this timing applies to the mandatory and optional commands specified in the Intelligent Platform 
Management Interface Specification. For controller-specific Application and Firmware commands, the Responder should 
attempt to meet this specification. In cases that it cannot, the interface specification for the Responder must clearly specify the 
‘Request to Response’ time that was implemented. Because timing can vary according to command and controller, 
communication routines should be designed to support response timeouts and retry counts accordingly. 


This is a recommended value only. The protocol does not require that non-Event Message requests be retried. The 
implementation of retries and the number used is based on the application’s requirements for message delivery. 
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13. IPMI LAN Interface 


This section describes the mechanisms specific to transferring IPMI messages between the BMC and a remote 
management system (remote console) over an Ethernet LAN connection using UDP under IPv4 or IPv6. The UDP 
datagrams are formatted to contain IPMI request and response messages, plus additional messages for discovery and 
authentication.d 


While an IPMI LAN interface can be accomplished using a LAN Controller that is dedicated to the BMC, it will 
usually be accomplished using LAN Controller that can be shared for both BMC and system use. 


There are two implementations that are likely to be used to deploy an IPMI LAN Interface using a shared LAN 
controller. The first implementation is using an embedded LAN controller, as shown in Figure 13-, and the second is 
using a LAN controller on an add-in card, as shown in Figure 13-. 


Both examples show a LAN Controller that has the capability to detect UDP datagrams sent to a ‘management port’. 
Any datagrams received on that port are forwarded to a ‘side-band’ interface that allows them to be delivered to, or 
retrieved by, the BMC. As Figure 13- shows, these incoming ‘platform management’ datagrams may also be 
delivered to system software in parallel with being delivered to the BMC. 


The BMC can use this same interface to inject datagrams onto the LAN. These datagrams are interleaved with the 
network packets that are generated by system software. 


The LAN Controller can be designed in such a way that the interface for the ‘management port’ is powered by 

standby power and remains operative even when the system is powered down. This provides a mechanism that 

allows IPMI LAN messaging to occur independent from system software and the system’s power state. A LAN 
controller dedicated to the BMC can also be used. 


Figure 13-, Embedded LAN Controller Implementation 


Managed System 
UDP datagrams to SEL, 
‘Mgmt. Port Datagrams | SDR, Satellite 
— bass gen'd by FRU Controller 
+ — — — — BMC | 
Te AAN kel aw fg PMB 
5 Controller 'side band 
ystem ) 
connection. 
| PCI E.g.SMBus | System Bus 
; or PC 
Outgoing packets 7 i 
All incoming 
from system 
packets 
software 


Figure 13- shows an implementation where the LAN Controller is implemented as a PCI add-in card connected to 
the BMC via a PCI Management Bus connection. This approach avoids the need to have the LAN Controller 
built-into the system, allowing the LAN Controller portion of the IPMI LAN Interface to be added or updated at a 
later time. 
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Figure 13-, PCI Management Bus Implementation 


LAN LAN 
Controller A Controller B 


Add-in Card 


IPMB 
BMC 


| System Bus 


13.1 RMCP 


The Distributed Management Task Force (DMTF) has defined a ‘Remote Management Control Protocol’ (RMCP) 
for supporting pre-OS and OS-absent management. RMCP is a simple request-response protocol that can be 
delivered using UDP datagrams. IPMI-over-LAN uses version | of the RMCP protocol and packet format. 


RMCP includes a field that indicates the class of messages that can be embedded in an RMCP message packet, 
including a class for IPMI messages. Other message classes are ‘ASF’ and ‘OEM’. 


IPMI v1.5 LAN messages are encapsulated in RMCP packets using the IPMI message class. An IPMI LAN 
implementation can also use ASF-class ‘Ping’ and ‘Pong’ messages to support the discovery of IPMI managed 
systems on the network. 


13.1.1 ASF Messages in RMCP 


The term ‘ASF’ is commonly used in RMCP. ASF originally stood for ‘Alerting Standard Forum’. This is the 
original name of a group that has moved into the DMTF as the Pre-OS Working Group. The group is 
standardizing a set of messages under RMCP that are oriented towards non-intelligent management hardware 
supporting basic LAN Alerting and recovery control (e.g. system reset) capabilities via the LAN. 


RMCP uses ‘ASF’ to denote the fields and values that support these messages. 


124 


Intelligent Platform Management Interface Specification 


13.1.2 RMCP Port Numbers 


RMCP uses two well-known ports under UDP. The following table describes these ports and summarizes their 


use. 
Table 13-, RMCP Port Numbers 
Port # Name Description 
623 Aux Bus Shunt Hereon referred to as the Primary RMCP Port - This port and the 
(26Fh) | (Primary RMCP required RMCP messages must be provided to be conformant with the 
Port) RMCP specifications. 
There is a mandatory set of messages that are required to be supported 
on this port. These messages are always sent ‘in the clear’ so that 
system software can discover systems that have RMCP support. 
664 Secure Aux Bus Hereon referred to as the Secondary RMCP Port or Secure Port. This 
(298h) | (Secondary port is only used when it is necessary to encrypt packets using an 
RMCP Port) algorithm or specification that prevents also sending unencrypted 


packets from being transferred via the same port. Since discovery 
requires sending ‘in the clear RMCP Ping/Pong packets, the secondary 
port is used to transfer encrypted transfers while the primary port 
continues to support unencrypted packets. 


An implementation that utilizes this port must still support the Primary 
RMCP Port and the required messages on that port in order to be 
conformant with the RMCP specifications. 


Note that the common IPMI messaging protocols and authentication 
mechanisms in this specification do not use encrypted packets at the 
RMCP level (encrypted packets in IPMI are defined under the IPMI 
message class), therefore IPMI messaging does not need to use the 
secondary port. 
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13. 


1.3 RMCP Message Format 


There are two types of RMCP messages: Data or ‘Normal’ RMCP messages, and RMCP Acknowledge 
Messages. Data messages and ACK messages are differentiated by the ACK/normal bit of the Class of Message 
field. 


Table 13-, RMCP Message Format 


size in 
Field bytes | Description 
RMCP Header 
Version 1 06h = RMCP Version 1.0 
Reserved 1 00h 
Sequence Number 1 varies, see text 
Class of Message 1 This field identifies the format of the messages that follow this header. 
All messages of class ASF (6) conform to the formats defined in this 
specification and can be extended via an OEM IANA. 
Bit 7 RMCP ACK 
0 - Normal RMCP message 
1 - RMCP ACK message 
Bit 6:5 Reserved 
Bit 4:0 Message Class 
0-5 = Reserved 
6 = ASF 
7 = IPMI 
8 = OEM defined 
all other = Reserved 
RMCP Data 
Data Variable | data based class of message 


The following table presents how the ACK/Normal Bit and the Message Class combine to identify the type of 
message under RMCP and which specification defines the format of the associated message data. 


Table 13-, Message Type Determination Under RMCP 


ACK/Normal Message 

bit Class Message Type Message Data 

ACK ASF RMCP ACK No Data. Message just contains RMCP Header with the 
Sequence Number set to the sequence number from the 
last message that was received. 

ACK all other undefined not allowed 

normal ASF ASF Messages | Per ASF Specification 

normal OEM OEM Message | bytes 0:3 = OEM IANA 

under RMCP 

bytes 4:N = OEM Message Data (defined by manufacturer 
or organization identified by the OEM IANA field value) 

normal IPMI IPMI Messages | Per this specification 

13.2 Required ASF/RMCP Messages for IPMl-over-LAN 
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The following class=ASF messages under RMCP must be supported in a system implementing the IPMI LAN 
interfaces over TCP/IP-UDP. This is just a specification of the minimum ASF message support required for 
IPMI LAN implementations. IPMI LAN messaging can coexist with additional ASF messaging on a system. 
Therefore, a system can support additional ASF messages and functions without being non-conformant with the 
IPMI LAN specifications. 
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There is no IPMI requirement for the BMC to respond to RMCP Messages of class=ASF other than the RMCP 


Ping message. However, additional message support may be required if the system is also to be conformant 


with the ASF specification. Refer to [ASF]. 


Table 13-, ASF/RMCP Messages for IPMI-over-LAN 


Message 
RMCP ACK 


Description 


RECOMMENDED for channels that are enabled 
for IPMI over LAN using IPv4 addressing, 
OPTIONAL when IPv6 addressing is used. 

Per the ASF specifications the RMCP ACK 
message should be returned whenever a ‘normal’ 
RMCP message with an RMCP sequence number 
of 0-254 is received. This is recommended, but not 
required for a system to be conformant with the 
IPMI LAN specification. (Note, however, that a 
system that does not return the ACK is not fully 
conformant with the RMCP specification). See 
sections 13.2.1, RMCP ACK Messages, and 
13.2.2, RMCP ACK Handling for more information. 


ASF Presence Ping message 


REQUIRED for channels that are enabled for IPMI 
over LAN using IPv4 addressing, 

OPTIONAL when IPv6 addressing is used. 

This message returns information about the 
interfaces supported via RMCP. It is used both to 
discover managed systems that support RMCP 
and to determine whether the system supports 
IPMI LAN messaging and/or additional ASF 
commands. 

This message must be supported on the Primary 
RMCP port. 


ASF Presence Pong Message (Ping response) 


REQUIRED for channels that are enabled for IPMI 
over LAN using IPv4 addressing, 

OPTIONAL when IPv6 addressing is used. 

This message must be returned from the managed 
system in response to the Presence Ping message 
on the Primary RMCP port. 


13.2.1 RMCP ACK Messages 


Table 12-5, RMCP ACK Message Fields, shows the RMCP header and data values for the RMCP ACK 


message. This message is used to acknowledge receipt of a ‘normal’ RMCP messages that were transmitted 


with a 0-254 RMCP sequence number. RMCP ACK messages are not generated if the RMCP sequence number 
is 255 (FFh). The RMCP ACK message does not indicate that an action has been completed, only that a specific 


RMCP packet has been received. 


The RMCP ACK operation is defined as being symmetric. That is, any party that receives a normal RMCP 
message with a 0-254 RMCP sequence number is supposed to respond with an RMCP ACK message. Thus, 


RMCP ACK messages can be generated by remote consoles and managed systems. 


Table 13-, RMCP ACK Message Fields 


Field 

Version 

Reserved 
Sequence Number 
Class of Message 


RMCP Data 


Value 


Copied from received message. 
Copied from received message. 
Copied from received message. 


[7] - 
[6:0] - 
none 


Set to 1 to indicate ‘ACK’ packet 
Copied from received message. 
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13.2.2 RMCP ACK Handling 


RMCP ACK messages are not required for IPMI messaging, since IPMI already has its own messaging retry 
policies. In addition, some Network Controllers usable for IPMI messaging do not automatically generate 


RMCP ACK messages. In these implementations, the BMC would have to generate the RMCP ACK, resulting 
in additional, unnecessary traffic from the BMC. Therefore, RMCP ACK messages should not be used for IPMI 


messaging. This leads to the following requirements and recommendations: 


e RMCP messages with class=IPMI must have their RMCP sequence number set to 255 (FFh) to indicate 
that RMCP ACK messages are not to be generated by the message receiver. 


e Console software should also set the RMCP sequence number to 255 (FFh) for non-IPMI messages, 
whenever possible. Some systems may not respond with an RMCP ACK for non-IPMI messages even if 
one was requested using a 0-254 RMCP sequence number. Console software should be prepared for this 
occurrence. The software can discover which systems support RMCP ACK by checking to see whether 
RMCP ACKs are generated as the result of sending RMCP Presence Ping messages. If RMCP ACKs are 
not received, the software should proceed without requiring RMCP ACK messages. 


e Regardless of whether RMCP ACK messages are received from a system, console software should still 
send RMCP ACKs whenever it receives an RMCP message with a 0-254 RMCP sequence number. 


13.2.3 RMCP/ASF Presence Ping Message 
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This message returns information about the interfaces supported via RMCP. It is used both to discover managed 


systems that support RMCP and to determine whether the system supports IPMI LAN messaging and/or 
additional ASF commands. The following table illustrates the specific fields to be used for Presence Ping 
Message to a system implementing IPMI LAN messaging. 


Table 13-, RMCP Packet Fields for ASF Presence Ping Message (Ping Request) 


UDP Header 


RMCP Header 


ASF Message 


size in 
Field bytes Value 
Source Port 
Destination Port 
UDP Length 
UDP Checksum 
Version 
Reserved 
RMCP Sequence Number 0-254 if RMCP ACK desired. 255 for no 
RMCP ACK. See sections 13.2.1, RMCP 
ACK Messages, and 13.2.2, RMCP ACK 
Handling for more information. 


Class of Message 06h for ASF 
IANA Enterprise Number 4542 (ASF IANA) 
Message Type 80h = Presence Ping 
1 


Message Tag DEER, generated by remote console. 
This is an RMCP version of a sequence 
number. Values 0-254 (0-FEh) are used 


for RMCP request/response messages. 
255 indicates the message is unidirectional 
and not part of a request/response pair. 


Reserved 
Data Length 00h 


1. Some systems may not generate RMCP ACKs even if requested. Software should be designed to 
handle this occurrence. 
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13.2.4 RMCP/ASF Pong Message (Ping Response) 


This message must be returned from the managed system in response to the Presence Ping message. 


Table 13-, RMCP Packet Fields for ASF Presence Pong Message (Ping Response) 


UDP Header 


RMCP Header 


ASF Message 


size in 
Field bytes | Value 

Source Port 
Destination Por 
UDP Length 
UDP Checksum 
Version 
Reserved 
RMCP Sequence Number 
Class of Message 
IANA Enterprise Number 
Message Type 
Message Tag 


Reserved 


Data Length 

IANA Enterprise Number If no OEM-specific capabilities exist, this 
field contains the ASF IANA (4542) and 
the OEM-defined field is set to all zeroes 
(00000000h). Otherwise, this field 
contains the OEM's IANA Enterprise 


Number and the OEM-defined field 
contains the OEM-specific capabilities. 


OEM-defined Not used for IPMI. 
This field can contain OEM-defined values; 
the definition of these values is left to the 
manufacturer identified by the preceding 
IANA Enterprise number. 


Supported Entities 1 81h for IPMI 
1b = IPMI Supported 
:4] Reserved 
:0] 0001b = ASF Version 1.0 


Supported Interactions 1 Set to 1b if RMCP security 
extensions are supported!!! 
Reserved for future definition by 
ASF specification. Set to 0b. 
Set to 1b if DMTF DASH is 
supported 
Reserved for future definition by 
ASF specification, set to 00000b 


Reserved Reserved for future definition by ASF 
specification, set to 00 00 00 00 00 00h 
1. IPMI v1.5 and IPMI v2.0/RMCP+ do not use RMCP security extensions specified in [ASF 2.0], thus 
this bit will typically be Obs. It’s possible a BMC implementation could also support ASF 2.0 
messages, in which case this bit could be set to indicate those extensions are supported for ASF 


messages that would utilize them. 


13.3 RMCP+ 


RMCP- is the name used in this specification for an enhanced protocol for transferring IPMI messages and other 
types of payloads to an IPMI-based BMC over IP. RMCP+ uses RMCP overall packet format, but defines 
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extensions to the fields defined under the IPMI Message Class data that is carried within the RMCP Packet. These 
extensions support enhanced authentication, encryption, discovery, and the ability to carry additional types of 
traffic (“payloads”) in addition to IPMImessages over an IPMI session, whereas v1.5 was only specified for 
carrying IPMI messages. Since RMCP+ is specified under the IPMI message class in RMCP, RMCP+ packets are 
conformant with the RMCP specification at the RMCP packet level. 


RMCP+ includes: 


e Support for multiple payload types over an IPMI session. These include both ‘standard’ payloads (such 
as the payload for the “Serial Over LAN” capability defined in this specification) and ‘OEM’ payloads. 
Payload support enables types of traffic other than IPMI messages to be simultaneously carried over an 
IPMI session. The specification also allows a separate session to be established for carrying payloads. 


e Enhanced user authentication algorithms. RMCP+ includes more robust session set-up and key handling 
algorithms than those for IPMI over LAN in IPMI v1.5. 


e Encryption support. IPMI messages and other payloads can be encrypted under an IPMI session. This 
enables confidentiality for remote operations such as setting user passwords and for SOL. 


e Better alignment with the ASF 2.0. RMCP+ follows many of the packet format and authentication 
elements defined for RMCP (Remote Management Control Protocol) as specified in the Distributed 
Management Task Force “ASF 2.0” specification. (See [ASF 2.0] in the Reference Documents section.) The 
session establishment messages and packet formats vary slightly from their ASF 2.0 counterparts, but are 
close enough to make it straightforward to create remote management applications that can support both 
ASF 2.0 and IPMI v2.0 -based remote management connections. 


e Supports Encrypted/Unencrypted and Authenticated/Unauthenticated Traffic on Single Connection. 
Encryption and Authentication are handled as the “IPMI Message Class” level. This means Authenticated 
and Encrypted sessions can be established on any UDP port, including port 26Fh. (This is different from 
ASF 2.0 which requires using a different port for authenticated traffic than the port used for unauthenticated 
messages.) IPMI allows a BMC to be configured so that authentication and encryption are only utilized 
when the payload or privilege level of operation requires it. This eliminates the need to have all traffic 
authenticated or encrypted on a connection, when only a small portion of the traffic may require that level of 
security. This can provide a a significant performance benefit when using inexpensive microcontrollers for 
BMCs. 


13.4 BMC Support Requirements for v1.5 and v2.0/RMCP+ Protocols 


An IPMI v2.0 conformant BMC (a BMC that reports v2.0 as the IPMI version in the Get Device ID command) 
that supports RMCP+ for IPMI messaging and standard payloads is required to simultaneously support IPMI v1.5 
Packet formats. For a given BMC, Users must be equally configurable for IPMI v2.0 or v1.5 IPMI Messaging 
access. 


IPMI v2.0-specific capabilities related to payloads (e.g. Serial Over LAN) are only available over IPMI 
v2.0/RMCP+ sessions. Otherwise, unless specified, new IPMI v2.0 commands and command extensions are also 
available under IPMI v1.5 sessions, provided the user has appropriate privilege. 


13.4.1 Session-less Command Support 


IPMI supports certain commands that can be delivered to the BMC without having to first establish a session. 
For backward compatibility and interoperability, the BMC shall always accept IPMI v1.5 formatted packets for 
messages that are accepted outside of a session. Le session-less commands that are common to both IPMI v1.5 
and IPMI v2.0/RMCP+ must be accepted in either format. For commands that are only used with IPMI 
v2.0/RMCP+, a BMC may elect to only accept those commands in IPMI v2.0/RMCP+ packets. Within a 
session, a BMC only accepts packets that are formatted for the type of session (v2.0 or v1.5) that was activated. 


130 


Intelligent Platform Management Interface Specification 


13.5 IPMI Messages Encapsulation Under RMCP 


For LAN transfers, IPMI messages are a special class of data encapsulated in an IPMI Session packet. The IPMI 
Session packets are encapsulated in RMCP packets, which are encapsulated in UDP datagrams. This is illustrated 
in the following figure. The same type of encapsulation is used for IPMI serial/modem messages via PPP, except 
the Ethernet Framing is replaced with a packet that uses PPP Framing and IP protocol type. 


Figure 13-, IPMI LAN Packet Layering 


Ethernet Framing 
MAC Address 


IP/UDP 
IP Address, RMCP Port # 


RMCP message 
Class=IPMI 
RMCP Sequence# = FFh 


IPMI v1.5 or IPMI v2.0+ 
Session Wrapper 


IPMI Message 
NetFn 

LUN 

Seq# 

CMD 

Data 


13.5.1 RMCP/ASF and IPMI Byte Order 


Please take note of the following: 


Multi-byte fields in RMCP/ASF fields are specified as being transmitted in ‘Network Byte Order’ - meaning 


most-significant byte first. 
RMCP and ASF-specified fields are therefore transferred most-significant byte first. 


The IPMI convention is to transfer multi-byte numeric fields least-significant Byte first. Therefore, unless 
otherwise specified: 
Data in the IPMI Session Header and IPMI Message fields are transmitted least-significant byte first. 
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13.6 IPMI over LAN Packet using IPv4 


The following table shows the format and fields for IPMI messages encapsulated in an RMCP packet that is 
itself encapsulated within an IPv4 UDP packet delivered over Ethernet. 


The table includes a set of columns under the label “Format”. The first column shows the format used for IPMI 
over LAN as originally defined in the IPMI v1.5 specification, the second column shows the format for 
authenticated packets delivered using RMCP per [ASF 2.0]. This column is shown for reference only. The third 
column shows the format of packets for RMCP+. 


Table 13-, RACP/RMCP + Packet Format for IPMI via Ethernet using IP v4 


Format 


RMCP / 
RMCP / ASF IPMI 2.0 
IPMI 1.5 RMCP “RMCP+” 
Field 26Fh 298h 26Fh Value 


802.3 


Source Address Source MAC Address for 
VE e 802.3 ë 090 


802. 1919 TPI Tag Protocol Identifier 
=8100h 


2 
VLAN TAG - user priority 3-bits 3-bits | User Priority" " 
default = 000b, configurable 
VLAN TAG -CFI ES EES EE Canonical Format Indicator 
= Ob 


| VLAN TAG -VLAN ID | 12-bits | 1 12-bits | oe EE 
Frame Type 2 0800h 
IP Header Version 
Header Length 4-bits 5h 
(length of IP header in units of 4- 
bytes) 
Precedence bi 
Service Type (Type of Service) 4-bits 1000b") 
(minimize delay) 
Total Length EE NEE ENE 


Identification] note?! 


EE GO oe eee 
Flags 3-bits 0106 
(don’t fragment) 


Fragment Ost 

Time-to-Live 

Protocol 

Header Checksum ma OE 

Source IP Address EE | 

Destination IP Address 

UDP Header Source Port N 
Destination Port 

UDP Length E ee 


UDP Checksum (36 bytes) Some payloads 
may not use the UDP 
checksum, in which case 


this field gets set to O's. The 


receiver must accept the 
packet and ignore the 
checksum field in this case. 


RSP Header Session ID 
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Session Sequence # 


Version 

Reserved 

RMCP Seq # 

Class of Message 
Auth Type / Format 


Payload Type 


OEM IANA 


OEM Payload ID 


IPMI v2.0 RMCP+ Session 
ID 


Session Sequence 
Number 


` NEE 


Msg. Auth. Code Code 
(AuthCode) 


06h (ASF 2.0) 


ee 
Paes i Pen | 
TEM 


[7:4] - reserved 


[3:0] - Authentication Type / 
Format 
Oh = none 
1h = MD2 
2h = MD5 
3h = reserved 
4h = straight password / 
key 
5h = OEM proprietary 
6h = Format = RMCP+ 
(IPMI v2.0 only) 
all other = reserved 
Payload Type 
[7] - Ob = payload is 
unencrypted 
1b = payload is 
encrypted 

[6] - Ob = payload is 
unauthenticated (no 
AuthCode field) 
1b = payload is 
authenticated 
(AuthCode field is 
present) 

[5:0] = payload type. See 
Table 13-, Payload 
Type Numbers. 

This field is only present 

when Payload Type = 02h 

(OEM Explicit) 

byte 1:3 - OEM IANA 

byte 4 - reserved 

This field is only present 

when Payload Type = 02h 

(OEM Explicit). The 

definition and values of this 

field are specified by the 
company or body identified 
by the OEM IANA field. 
note! Session ID is 
0000_0000h for messages 

that are sent ‘outside’ of a 

session. 

notel®! For IPMI v2.0 

"RMCP+" there are 

separate sequence 

numbers tracked for 
authenticated and 
unauthenticated packets. 
0000_0000h is used for 
packets that are sent 

‘outside’ of a session. 


notel®! Session ID is 


0000_0000h for messages 
that are sent ‘outside’ of a 
session. 


ii. AE aa] 
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(not present when 
Authentication Type set to 
‘none’.) 
IPMI Msg/Payload 
length 


IPMI Payload Confidentiality Header 


Payload Data 


Confidentiality Trailer 


Payload length in bytes. 
1-based. 


For encrypted payloads, 
based on encryption type 
for given payload. The 
confidentiality header is not 
encrypted. 

For IPMI v2.0: IPMI, SOL, 
KVM, etc. per Payload 
Type field. 

For encrypted payloads, 
based on encryption type 
for given payload. The 
confidentiality trailer is 
typically encrypted along 
with the Payload Data. 


IPMI Session 
Trailer / 
RSP Trailer 


Integrity PAD 


Added as needed to cause 
the number of bytes in the 
data range covered by the 
AuthCode (Integrity Data) 
field to be a multiple of 4 
bytes (DWORD). If present, 
each Integrity Pad byte is 
set to FFh. 


Pad Length 


Next Header 


AuthCode (Integrity Data) 


indicates how many pad 
bytes were added so that 
the amount of non-pad data 
can be determined. 
Reserved in IPMI v2.0. Set 
to 07h for RMCP- packets 
defined in this specification. 
For IPMI v1.5 this field is as 
specified by Auth Type. 


For IPMI v2.0 (RMCP+) if 
this field is present, then it 
is calculated according to 
the Integrity Algorithm that 
was negotiated during the 
session open process. See 
Table 13-, Integrity 
Algorithm Numbers. 


This field is absent when 
the packet is 
unauthenticated. 


Legacy PAD!" 


MAC level CRC 


legacy PAD not needed for 
IPMI v2.0 


1. Some LAN adapter chips may have a problem where packets of overall lengths 56, 84, 112, 128, or 156 are not 
handled correctly. The PAD byte is added as necessary to avoid these overall lengths. Remote console software 
must use the PAD byte when formatting packets to any 10/100 Ethernet device that accepts RMCP packets. 


2. ØMCP Messages with class=IPMI should be sent with an RMCP Sequence Number of FFh to indicate that an RMCP 
ACK message should not be generated by the message receiver. 


3. Default value for packets transmitted from the BMC. Can be overridden via a configuration parameter setting. 
Value used for packets transmitted from the BMC. The BMC ignores the value of this parameter (except for 


checksum calculations) on received packets. 


5. BMC should increment this field each time it sends a new packet. 
6. Default value for packets transmitted from the BMC. Bit offset 1 (fragment bit) can be overridden via a configuration 


parameter setting. 
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Default value for packets transmitted from the BMC. The BMC is not required to support receiving fragmented 
packets. Packets with a non-zero fragment offset and/or a flags field bit 2 = 1b (“more fragments” may be silently 
discarded.) 


The Session ID and Session Sequence Number must be non-zero for commands executed during an active session. 
All O's (0000 0000h) for the Session ID and/or Session Sequence Number (null Session ID, null Session Sequence 
Number) are special values only used for messages and commands that can be executed prior to establishing a 
session, e.g. Get System GUID, Get Channel Authentication Capabilities, Get Session Challenge, and RAKP 
messages. When the Session ID is 0000_0000h, the Sequence Number field is ignored, however the Session 
Sequence Number should still be set to 0000 0000h. In addition, for IPMI v2.0 RMCP+ packets, unless otherwise 
indicated bits 7:6 in the payload type field must also indicate that the packet is both unauthenticated and 
unencrypted. Note that the IPMI v1.5 Activate Session uses a null (all 0’s) Session Sequence Number before a 
session is activated, but does not use a null Session ID. Instead, it uses the Temporary Session ID given by the 
BMC in the response to the Get Session Challenge command. 


For IPMI v2.0 RMCP+ packets, the IPMI Session Trailer is absent whenever the Session ID is 0000_0000h, or 
whenever bit 6 in the payload type field indicates the packet is unauthenticated 


Four bytes only present for IEEE 802.1q “VLAN” formatted packets 
The use and interpretation of this number is defined in ISO/IEC 15802-3. 


MI over LAN Packet Using IPv6 


The following table presents the packet format that is used for IPMI messages and payloads that are transferred 
over an IEEE 802.3 Ethernet connection using IPV6. 


Table 13-8a, RMCP/RMCP+ Packet Format for IPMI via Ethernet using IPv6 


Field Field Size in bytes (-bits) Value / Notes 


IP Header?! 


UDP Header 


RMCP Header 


Destination Address eae ET Dest. MAC Address for 
802.3 


Source Address Source MAC Address for 
802.3 


TPI Tag Protocol Identifier 
=8100h 


VLAN TAG - user priority 3-bits User Priority! 
default = 000b, configurable 
VLAN TAG - CFI Canonical Format Indicator 
= Ob 


VLAN TAG - VLAN ID 12-bits 0’s = no VLAN 

[Frame Tye | 2. fi 080m oS 
Version TOE 
Traffic Class 


Flow Label 20-bits 00000h (default for 
outgoing packets, 
configurable. Ignored on 
incoming packets.) 


Payload Length E (Ee 
Next Header 
Hop Limit 
Source IP Address HE EE 
Destination IP Address SS EE 

Source Port GE 2 ENE 

Destination Port ee 


UDP Length 
es ee for IPv6. 
Calculated per [RFC2460] 


UDP Checksum 
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IPMI Session Same as for IPv4 “RMCP+”. Refer to the specification for RMCP / IPMI 2.0 
Header "RMCP+" in Table 13-8, RMCP/RMCP+ Packet Format for IPMI via Ethernet. 


IPMI Payload 
IPMI Session 
Trailer!" 
RSP Trailer 
MAC level CRC 4 


1. For IPMI v2.0 RMCP+ packets, the IPMI Session Trailer is absent whenever the Session ID is 0000 0000h, or whenever bit 6 
in the payload type field indicates the packet is unauthenticated. 
2. These four bytes (TPI through VLAN TAG - VLAN IDn field) are only present for IEEE 802.1q “VLAN” formatted packets. 


3. IP Header per [RFC2460] 


13.7 VLAN Support 


VLAN support is optional, but recommended, for BMC access via IPMI 1.5 packet and IPMI v2.0 packet formats. 
A BMC that supports VLAN on a channel is required to support it for both packet formats. A BMC is not required 
to support VLAN equally across all LAN channels. This is allowed because some LAN connections may not have 
hardware that supports VLAN with a LAN connection to the BMC. 


When a VLAN ID is configured into the LAN parameters, the BMC will only accept packets with that VLAN tag. 
This includes all RMCP and RMCP+ packets as well as DHCP and ARP packets. Conversely, all BMC-generated 
packets will include the given VLAN tag. 


13.8 IPMI LAN Message Format 


The encapsulated IPMI Messages are based on the same format as specified for the IPMB. This is done for 
consistency and simplification of bridging operations. There is one significant difference. For IPMB messages, the 
requester and responder addresses are always 7-bit DC slave addresses. For IPMI LAN messages, the addresses 
can be either slave addresses or software IDs. The least significant bit of the responder’s address and requester’s 
address field indicates which type of address is being used, as described below. 


There is no linkage between inbound and outbound messages and whether the message is a request or a response 
message. Inbound messages can be either request or response messages and outbound messages can be request or 
response messages. 


The following table presents the formats for request and response messages: 


Figure 13-, IPMI LAN Message Formats 
Request 


rsAddr. net Fn checksum 
(SA or sw ID) (even) / rsLUN 


rqAddr. rqSeq /rqLUN cmd request data bytes checksum 
(SA or sw ID) (0 or more) 
Response 
rqAddr. net Fn checksum 
(SA or sw ID) (odd) /rqLUN 


rsAddr. rqSeq /rsLUN cmd completion response data checksum 
(SA or sw ID) code bytes (0 or more) 
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Where: 
checksum 2's complement checksum of preceding bytes in the connection header or between the 
previous checksum. 8-bit checksum algorithm: Initialize checksum to 0. For each byte, 
checksum = (checksum + byte) modulo 256. Then checksum = - checksum. When the 
checksum and the bytes are added together, modulo 256, the result should be 0. 
cmd Command Byte 


completion code 
data 


Completion code returned in the response to indicated success/failure status of the request. 
As required by the particular request or response for the command 


LUN The lower 2-bits of the netFn byte identify the logical unit number, which provides further 
sub-addressing within the target node. 

netFn Network Function code 

rq Abbreviation for ‘Requester’. 

rqLUN Requester’s LUN. 

rqAddr Requester's Address. 1 byte. LS bit is 0 for Slave Addresses and 1 for Software IDs. Upper 
7-bits hold Slave Address or Software ID, respectively. This byte is always 20h when the 
BMC is the requester. 

rqSeq Sequence number, generated by the requester. 

rs Abbreviation for ‘Responder’. 

rsLUN Responder’s LUN 

rsAddr Responder's Slave Address. 1 byte. LS bit is 0 for Slave Addresses and 1 for Software IDs. 
Upper 7-bits hold Slave Address or Software ID, respectively. This byte is always 20h 
when the BMC is the responder. 

Seq Sequence number. This field is used to verify that a response is for a particular instance of 


a request. Refer to [IPMB] for additional information on use and operation of the Seq field. 


13.9 LAN Alerting 


LAN Alerts are accomplished by generating a UDP Datagram that contains an SNMP Trap formatted per the 
IPMI Platform Event Trap (PET) Format specification. This same format is used for PPP alerts generated over the 
serial/modem interface when operating in PPP/UDP mode. Information for the PET trap comes from the Event 
Message that generated the alert and from the LAN configuration parameters for PET. 


13.10 IPMI LAN Configuration 


This section provides background information on certain configuration options that are available for LAN 
channels and how they’re used. 


13.10.1 IP and MAC Address Configuration 


The BMC in the managed system needs the system’s IP Address and MAC Address in order to be able to 
respond to UDP/IP packets or generate LAN alerts. 


A BMC implementation is not required to be able to run DHCP or other protocols to keep it’s IP address 
assignment up-to-date. In such implementations, it is the responsibility of system software to keep this address 
information current in case it might change (as could be the case if the lease expired on an IP address, perhaps 
because the system was unplugged for a long time). 


It is recommended that system software periodically check the BMC’s address assignment to see if it is current, 
and to update it if it’s not. It is also recommended that the BIOS run DHCP and initialize the BMC IP address 
on startup if the BMC implementation does not include built-in DHCP support. 
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13.10.2 ‘Teamed’ and Fail-over LAN Channels 


It is possible that an implementation may have multiple network controllers connected to the BMC. In such a 
configuration, it may be desirable to support a configuration where multiple network controllers share the same 
IP address. This ‘teamed’ configuration provides a bandwidth improvement by allowing messages to that IP 
address to be sent and received by multiple NICs. Similar arrangements can be used to offer ‘fail-over’ 
capability where one NIC will be activated if another fails. 


Teaming and fail-over require special system software and driver support that is outside the scope of this 
specification. However, it should be noted that IPMI Sessions could be implemented in a manner that can 
facilitate such applications. One useful approach is to design the implementation such that Session IDs are 
unique across all channels. That way, if two LAN channels were configured with the same IP address, the BMC 
could accept session traffic that was split across the two channels. Since user information is channel-specific, it 
would also be necessary for the user data and other configuration options to be identically configured. An 
alternative implementation may provide a proprietary option where the two LAN connections are combined into 
a single logical channel when teaming is in effect. 


Note: The maximum operating privilege level and authentication will be determined by the user privilege 
and channel privilege limit settings. Since these can vary on a per channel basis, it is possible that unless 

the channels are configured identically a different maximum operating privilege level will be seen based 

on which channel a message is received on. 


13.11 ARP Handling and Gratuitous ARP 


For Ethernet, the Address Resolution Protocol (ARP) [RFC826] allows a host to find the physical address (MAC 
address) of a target host on the same network, given only the target's Internet address. Systems and routers cache 
IP Address-to-MAC Address information so they do not need to perform ARP requests every time they 
communicate with another system. This cache is commonly referred to as an ARP Cache. 


ARP Requests are broadcast. The request contains the IP Address for which an ARP Response containing the 
MAC address is desired. The sender's IP Address-to-MAC Address mapping is also in every ARP request 
broadcast. This allows receivers to update their own caches with the sender’s information before responding to the 
ARP request. 


A Gratuitous ARP is an ARP Response where the responder sends out the internet-to-physical mapping of its own 
IP Address. Since the sender’s internet-to-physical address mapping is part the request, receivers use that 
information to update their own caches with the sender’s address mapping. 


It is common for systems to do a Gratuitous ARP on startup to inform other machines of its address (possibly a 
new address). This gives the other systems a chance to update their ARP cache entries immediately. A Gratuitous 
ARP at startup can also be used as a way to check whether another system is already using the system’s IP 
address. 


For this version of the specification, Gratuitous ARP capability is only described for Ethernet LAN channels. 


13.11.1 OS-Absent problems with ARP 


Some BMC LAN implementations may only have the ability to only receive UDP packets that are addressed to 
the RMCP ports. Since Ethernet ARP packets are not UDP packets, Ethernet ARP request packets would not get 
routed to the BMC. Thus, when the system is in a powered down state, the system may not accept ARP Requests, 
or the request may not be able to be seen by the BMC, and the ARP Request will not get responded to. This means 
that a remote application that relies on ARP to get the MAC address will not be able to connect to the managed 
system once the system has powered down or is in a sleep state and the remote application’s or intermediate 
router’s ARP cache entries expire. 
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13.11.2 Resolving ARP issues 


The following are possible approaches to eliminating or reducing issues that can occur if the BMC LAN 
implementation cannot receive or respond to ARP Requests while the system is powered down or sleeping. It is 
also possible for this to happen if the run-time software does not use the network. This could happen while in a 
failed state or if the system has booted to ‘DOS’ or a local diagnostic partition. 


e Increase ARP Cache expiration intervals in routers and applications. 


e Implement Proxy ARP on the subnet - implement Proxy ARP software (software that responds to ARP 
Requests on behalf of the managed systems) on one or more systems on the subnet. At least one of the 
Proxy ARP systems must remain powered up. 


e Have the application maintain the ARP table - This only works if the remote console application is on the 
same subnet as the managed system. Some network stacks include an arp utility program that allows ARP 
entries to be manually entered into the ARP table (cache) for that system. An application could use this 
mechanism to maintain the ARP table with a ‘fixed’ IP-to- MAC address association for the system. 


e Use a router with Proxy ARP capability - Some routers can be configured to provide a Proxy ARP 
capability 


e Wake-On-LAN - If the managed system supports Wake-On-LAN it may be used to wake the system in 
order to allow system software to respond to a later ARP Request. 


e Use a Network Controller with built-in ARP Response capability. As out-of-band management using 
RMCP becomes more popular, network controller vendors may offer controllers with the ability to directly 
respond to ARP Requests when the system is powered down or sleeping. 


e Provide Gratuitous ARPs from the BMC. If the BMC LAN connection allows the BMC to send ARP 
Requests, then the BMC could periodically issue Gratuitous ARPs. Many routers and network stacks will 
accept this Gratuitous ARP in place of an actual ARP response packet. 


The best solution is to have an implementation where the BMC or Network Controller directly responds to ARP 
Requests during times that the OS does not. If this is not possible, having the BMC issue Gratuitous ARPs can 
often work well as a substitute. Because BMC-generated Gratuitous ARPs and ARP Responses may be 
common, this specification includes commands that can be used for configuring and controlling those 
capabilities if they exist in the implementation. 


13.11.3 BMC-generated ARPs 


A BMC LAN implementation may support BMC-generated Gratuitous ARPs or BMC-generated ARP 
responses. If either of these options are supported, the BMC shall also support the BMC-generated ARP Control 
LAN configuration parameter. 


The term “BMC-generated” in this case means that the Gratuitous ARP or ARP Response generation is under 
direct control of the BMC. The actual logic for sending the ARP packet may be in another device. For example, 
a Network Controller chip may have the ability to be enabled by the BMC through a private interface. 


It is possible that run-time software will want to take over the responsibilities for ARP handling during run- 
time. A BMC implementation that supports BMC-generated ARPs should also support the Suspend BMC ARPs 
command. This command allows system management software to suspend BMC-generated ARPs while the 
Watchdog Timer is running. Refer 23.3, Suspend BMC ARPs Command for more information. 


13.12 Retaining IP Addresses in a DHCP Environment 


DHCP (Dynamic Host Configuration Protocol) is an UDP-based protocol that is primarily used to allow 
systems to obtain an IP Address from a DHCP Server on the network. This address assignment is ‘leased’ and 
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will expire if the assignment is not refreshed by the time the lease expires. The BMC LAN implementation may 
not be able to run DHCP. This could be because the BMC LAN implementation may only have the ability to 
send and receive via the RMCP port addresses, preventing it from running standard DCHP. 


If the BMC itself cannot run DHCP, the BMC must rely on the IP Address assignment that is configured into 
the LAN Configuration Parameters. Typically, system software be able to keep the address assignment while 
the system is running. This can either occur as a consequence of having sufficient IP traffic activity occur to 
keep the lease, or if the system may be idle for long periods of time, a software agent could be written that 
periodically refreshes the assignment. 


A more serious issue can occur while the system is powered down or sleeping. If the system is powered down 
or is sleeping for a sufficiently long time, the IP Address could be lost due to expiration of the DHCP lease. 
When the system starts up again, the BMC will need to get a new IP address assignment into its configuration 
parameters. 


13.12.1 Resolving DHCP issues 


The following are possible approaches to eliminating or reducing issues that can occur if the BMC LAN 
implementation cannot perform DHCP while the system is powered down or is sleeping: 


e If possible, configure Static IP addresses for your managed server systems. DHCP Servers can typically be 
configured to deliver fixed IP addresses for a given MAC address. 


e If you have to use leased IP addresses, configure long lease intervals for the addresses. 


e Have a system management software agent that checks the IP Address assignment and updates the BMC if 
the assignment changes. 


e Have the BIOS perform DHCP and update the BMC when the system powers up or resets. This helps 
safeguard against changes to the IP address that may have occurred when the system was powered down or 
sleeping. It also helps ensure that the BMC as an IP Address assignment if booting to an alternate OS or 
service partition, and provides a mechanism for getting an IP address for BMC LAN even before the system 
has an OS loaded. 


e Enable Wake-On-LAN capabilities. This capability can be used to allow a remote console to occasionally 
wake the system to ensure that the IP Address assignment is retained or updated. 


In general, a system in a DHCP environment will typically be used frequently enough to never lose its address 
assignment. If run-time software and BIOS can keep the BMC up-to-date with IP address assignment changes, 
the need to refresh assignments while the system is powered-down or sleeping may not be an issue in many 
environments. 


13.12a IPMI over LAN and LAN Alerting using IPv6 
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IPv6 Addressing for RMCP+ (IPMI over LAN) and LAN Alerting is an optional feature for IPMI v2.0. The 
specification supports both static and dynamic address assignment for the BMC and static configuration and 
dynamic address discovery for routers. The abbreviation *SLAAC” is used when referring to IPv6 StateLess 
Address Auto Configuration. 


If supported per this specification, the implementation shall meet the requirements described in the following 
sections. Additionally: 


e Supporting IPv6 for LAN Alerting assumes the implementation supports for IPv6 Addressing for RMCP+ 
(IPMI over LAN). 
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e The LAN Configuration Parameters for IPv6 Addressing and LAN Alerting using IPv6 Addressing should 
not be implemented unless IPv6 Addressing is supported per this specification. 


e IPv6 Addressing is only specified for RMCP+ and IPMI v2.0. 


e An implementation is not required to support simultaneous IPv4 and IPv6 sessions. A LAN Configuration 
Parameter reports the implementation’s capabilities for supporting IPv4 and IPv6. 


13.12b Indicating Support for IPv6 


The “IPv6/IPv4 Support” LAN Configuration Parameter indicates whether IPv6 Addressing is supported for BMC 
and LAN Alerting. This parameter shall be supported if IPv6 Addressing is supported per this specification. 
Otherwise, the parameter should not be supported. 


13.12c IPv6 BMC Address Configuration Requirements 


If IPv6 addressing is supported, the IPMI LAN Configuration Parameters can be used to configure static and/or 
dynamic address assignment for the BMC if IPv6 addressing is supported. 


An implementation has a number of options regarding the IPv6 address configurability it supports. Unlike the 
IPv4 configuration parameters, the IPv6 parameters allow a BMC implementation to respond to more than one IP 
Address. The following table summarizes the requirements for the Static Address Max and Dynamic Address 
Max values based on the implementation’s support for static and/or dynamic addresses. 


The “IPv6 Status” configuration parameter indicates whether only static, only dynamic, or both static and 
dynamic address configuration is supported, as well as how many possible addresses may be usable for 
establishing an IPMI LAN session. 


Table 13-8b, IPv6 Address Configuration Requirements Based on Implementation 


Static Host (BMC) Dynamic Host (BMC) 
5 Address Address 
pene non Sapone. Configuration Configuration 
requirement requirement 
Static only 1 minimum none 
Static and Dynamic 1 minimum 1 minimum 
Dynamic only none 1 minimum 


13.12d IPv6 Router Address Configuration Requirements 


For RMCP+ sessions, the BMC typically just sends packets to the remote IPv6 IP Address and MAC Address that 
was used to establish the session and there’s no need for IPv6 to MAC Address resolution. 


When the BMC needs to initiate a transmission, as is the case when sending an alert, it needs to resolve the alert 
destination’s IP Address the MAC address of the ‘on link’ destination, or the MAC address of the appropriate 
router if the destination is ‘off-link’. 


The BMC always uses Neighbor Discovery [RFC4861] and the Solicited Node Multicast Address to resolve ‘on- 
link’ IPv6 Addresses into their respective MAC addresses. 


If a static router configuration is not used, the BMC also uses Neighbor Discovery Router Solicitation and Router 
Advertisement messages to obtain the router’s MAC address and link prefix information. 
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Table 13-8c, IPv6 Router Configuration Requirements Based on Implementation 


Implementation supports: Static Router Dynamic Router 
Address Address 
Configuration Configuration 
requirement requirement 
Static only 2 minimum none 
Static and Dynamic 2 minimum 2 minimum 
Dynamic only none 2 minimum 


13.12e IPv6 Router Configuration Capability and Reporting 


If IPv6 addressing is supported, IPv6 router addresses can be specified statically, or can be obtained dynamically 
through SLAAC or DHCPv6. The LAN Configuration Parameters include parameters that are used to configure 
static or dynamic router addressing. The parameters also include a optional parameters that can be used to report 
addressing information that has been received when dynamic router addressing is used. 


13.12f Static Router Address Configuration 


The “IPv6 Router Address Configuration Control” LAN onfiguration parameter is used to select whether static 
router addresses are used for the BMC. 


If static router configuration is used, the BMC does not use Neighbor Discovery to discover the router and to 
obtain the router’s MAC Address, but instead uses the IPv6 Static Gateway MAC Address parameter alone as the 
router’s MAC Address for routing off-link IP Addresses. The BMC also does not use Neighbor Discover to obtain 
the prefix information for on-link addresses. Instead, the IPv6 Prefix Length parameter is used to determine how 
many bits of the most-significant IPv6 IP Address bits are to be considered the ‘prefix’ bits that identify the 
subnet and which remaining bits are the node-specific part of the address. Thus, when static router configuration 
is used, the BMC does not need to send any multicast messages to on-link routers. 


13.12g Dynamic Router Addressing Requirements 


When routers are dynamically discovered, either as part of supporting Neighbor Discovery / SLAAC or because 
dynamic router addressing was selected via the “IPv6 Router Address Configuration Control” parameter, the 
BMC shall store dynamic address information for at least two routers, and support at least two prefixes from each 
router. 


The behavior is unspecified if a router gives the BMC more prefixes than it can store. The choice of which ones to 
keep and which to discard is implementation-specific. The BMC may consider factors such as the prefixes match 
the prefixes for existing alert destinations or are prefixes for reaching other off-link services, such as DHCP 
servers. 


The behavior is unspecified if the BMC receives advertisements from more routers than it can track. It is 
implementation-specific whether BMC updates with new information or keeps existing router addresses and 
associated prefixes/lease info. The BMC may consider factors such as whether a given advertisement includes 
information that matches prefixes for existing Alert Destinations. 


13.12h Neighbor Solicitation Message Handling Requirements 
If IPv6 Addressing is enabled, the BMC shall always respond to any Neighbor Solicitation messages that contain 


a conflicting address with a corresponding Neighbor Advertisement message indicating the address is already in 
use. 


142 


Intelligent Platform Management Interface Specification 


When a static address is used as an IPv6 Address Source, the BMC may choose to use the Neighbor Solicitation 
message to check whether this address is already in use by another device. If a conflict is detected, the BMC 
should not attempt to use the address, but just report the conflict using the “IPv6 Static Address Status” parameter. 


13.121 IPv6 and DHCPv6 Timing Configuration 


The LAN Configuration Parameters include the option of configuring standard timing parameters for DHCPv6 
and/or Neighbor Discovery / SLAAC. Refer to Sections 23.2a, DHCPv6 Timing Parameters, and 23.2b, Neighbor 
Discovery / SLAAC Timing Parameters, for more info. 


13.12] Alert Processing for IPv6 


Retries and/or positive acknowledge are configured via the Destination Type parameter (same as for IPv4 Alert 
Destinations). 


When processing the IPv6 address for an Alert Destination, the BMC shall first check the upper bits of the 
destination address for a match with the prefix of the IPv6 address presently assigned to the BMC. If there's a 
match, the BMC shall send the alert using link-local addressing. 


Next, if the Alert Destination address is off-link and static router addresses are enabled, the BMC shall check the 
address against the static router and prefix parameters and send the alert to the router that has the longest 
matching prefix. 


Otherwise, if dynamic router addressing is enabled, the BMC shall send the alert to the router address with the 
longest, unexpired, matching prefix that the BMC has received. 


The behavior is implementation-specific if there is no matching prefix. The BMC is allowed to simply drop the 
alert or it may try to first take actions such as sending out additional Router Solicitation requests in an attempt to 
discover a router that supports a matching prefix for the Alert Destination. 


The BMC may use Neighbor Unreachability Detection to verify communication with the destination address prior 
to sending the alert. The BMC sends a neighbor solicitation and waits for a solicited neighbor advertisement and if 
a corresponding solicited neighbor advertisement is received, the neighbor is considered reachable. 


13.13 Discovering Support For IPMI over IP Connections 


There are two mechanisms for discovering whether a given system (IP Address) supports IPMI v1.5 and/or IPMI 
v2.0 connections. The first is the ‘RMCP Ping discovery’ mechanism where the BMC returns whether IPMI is 
supported via the supported entities field of the Ping response (a.k.a. the ‘Pong’ message). The BMC can 
optionally return values in the Ping response indicating what level of IPMI connection(s) (IPMI v1.5 and/or IPMI 
v2.0) it supports. 


The second mechanism is an ‘IPMI command discovery’ mechanism where the remote console discovers that the 
system supports IPMI by issuing a Get Channel Authentication Capabilities command to determine support for 
IPMI v1.5/IPMI v2.0 connections. BMCs that support IPMI v2.0/RMCP+ must support the Get Channel 
Authentication Capabilities command in both the IPMI v1.5 and IPMI v2.0 packet formats. It is recommended 
that a remote console use the IPMI v1.5 formats until it has confirmed IPMI v2.0 support. 


When the remote console decides to connect to the discovered system, it can use the Get Channel Authentication 
Capabilities and (for IPMI v2.0/RMCP+) the Get Channel Cipher Suites commands to determine which 
authentication, integrity, and confidentiality algorithms can be used for establishing the connection. 


143 


Intelligent Platform Management Interface Specification 


13.14 IPMI v1.5 LAN Session Activation 


The LAN Channel is an authenticated multi-session connection. Messages delivered to the BMC via LAN are 
optionally authenticated using the session authentication mechanisms and challenge/response protocol described 
in section 6.12.7, IPMI v1.5 Session Activation and IPMI Challenge-Response. Also refer to sections 6.9, Users & 
Password Support, and 6.12.3, Multi-session Connections. 


In addition, a LAN implementation supports discovery via the RMCP Ping/Pong mechanism as a step that 
typically precedes the session activation phase. 


The following presents an overview of the steps that are used by a remote console to establish a IPMI Session via 
IPMI LAN. These are also illustrated in Figure 13-, IPMI v1.5 LAN Session Startup, below. 


1. 
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The remote console discovers the system by issuing an RMCP Presence Ping message. The response called 
the Presence Pong message, returns a bit indicating whether the platform supports IPMI, and whether the 
platform uses just the Primary RMCP Port (26Fh) or both the Primary RMCP Port and the Secondary/Secure 
RMCP Port (298h). 


If the system supports IPMI, the remote console starts the process of establishing a session by sending a Get 
Channel Authentication Capabilities command packet with Authentication Type = none (“in clear”). The 
response packet will contain information regarding which type of challenge/response authentication is 
available to be utilized. 


The console then requests a session challenge by issuing a Get Session Challenge request, also with 
Authentication Type = none. The request contains information indicating what type of authentication type the 
console wants to use. This must be one of the supported types returned by the Get Channel Authentication 
Capabilities command. The response packet will contain a challenge string and a Session ID. 


The console then activates the session by issuing an Activate Session request. The Activate Session packet is 
typically authenticated. For message-digest algorithms, the packet includes a signature (AuthCode) that is a 
hash of the challenge, the Session ID, the password, and the message data, using one of the supported 
algorithms from the Get Channel Authentication Capabilities command. The console also sets the initial 
value for the Outbound sequence number that it wants the BMC to use for packets it sends to the console. 


The BMC returns a response confirming that the Session has been successfully activated. It also returns the 
Session ID to be used for the remainder of the session, and the initial Inbound session sequence number that it 
wants the remote console to use for subsequent messages it sends to the BMC for that session. The Activate 
Session response is also authenticated (signed) in the same manner as the request was. This allows the remote 
console to validate that it has a correct Session ID. Note that IPMI does not support switching authentication 
algorithms ‘mid stream’. The algorithm used with the Activate Session command is the algorithm that will be 
used for subsequent authenticated messages for the session. The exception to this is that the ‘none’ 
authentication type is allowed if options such as ‘Per-Message Authentication’ and/or ‘User Authentication’ 
are disabled. 
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Figure 13-, IPMI v1.5 LAN Session Startup 


Remote Console Managed System 


RMCP Ping 


> 
Pa 
Q RMCP "Pong" 
3 pust (Ping response) 
Oo SessionID=0, Sess. seq# = 0, 
Auth. type =None, AuthCode = 
å A not present [Requested maximum 
Get Channel Authentication] privilege level = Operator] 
Capabilities, Rq Sn 
(Console requests information on what ern 
authentication algorithms must be used to SessionID=0, Sess. seq# = 0, 
connect at a given maximum privilege level, Auth. type =None, AuthCode = å : 
e.g. Operator) not present [Auth Type(s) = MD2, _ Get Channel Authentication 
MD5] eg Capabilities, Rs 
Be (BMC returns which authentication algorithms can 
be used for connecting at requested maximum 
privilege level [e.g. MD2 & MD5]) 
SessionID=0, Sess. seq# = 0, 
Auth. type =None, AuthCode = 
not present [username, Auth Type 
Get Session Challenge, Ra@—=™21 
(Console requests a challenge for given — 
user and using MD2 authentication type) 
5 SessionID=0, Sess. seq# = 0, 
= Auth. type =None, AuthCode = 
not present, [Challenge, temp A 
2 session ID] Get Session Challenge, Rs 
E ME GERE (BMC returns challenge string and 
temporary session ID) 


SessionID=temp, Sess. seq# = 0, 
Auth. type =MD2, AuthCode = 

MD2(), [challenge, Outbound 
Seq=mm] 


Activate Session, Rq 
(Console delivers signed request using 
temporary session ID, console also selects 
the outbound sequence number it want the 
BMC to use) 


SessionID=temp, Sess. seq# = 0, 
Auth. type =None, AuthCode = 


MD2(), [SessionID, Inbound Sess. . å 
Activate Session, Rs 


seq#=nn] e 
Ber ` (BMC returns a signed packet with the session ID 


to be used for the active session. BMC also returns 
the inbound sequence number it wants the console 


SessionlD, Sess. seq# = nn, 

Auth. type =MD2, AuthCode = 

SES MD2(), [desired priv. level] 
Set Privilege Level, Rq = 

(from this point, all packets in the session 

use the assigned Session ID and session 


Q sequence numbers starting from the z 
5 inbound and outbound sequence numbers SessionID, Sess. seq# = mm, 
E that were exchanged using the Activate Auth. type -MD2, AuthCode = 
Session command) MD2(), [completion code] Set Privilege Level, Rs 
D 
D 
D 


13.15 IPMI v2.0/RMCP+ Session Activation 


This section describes the process that is used for authenticating the user’s credentials and establishing an IPMI 
session using RMCP+. The messages for RMCP- are specified under the IPMI Message class (07h) for RMCP. 
The payload type field in the RMCP+ packet format is used to identify the messages that are used for activating a 
session under RMCP+. The following messages are used to activate a session using RMCP+: 
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Get Channel Authentication Capabilities request / response 
This message exchange provides a way for a remote console to discover what IPMI version is supported. 
Le. whether or not the BMC supports the IPMI v2.0 / RMCP+ packet format. It also provides information 
that the remote console can use to determine whether anonymous, “one-key”, or “two-key” logins are used. 
This information can guide a remote console in how it presents queries to users for username and password 
information. This is a ‘session-less’ command that the BMC accepts in both IPMI v1.5 and v2.0/RMCP+ 
packet formats. 


RMCP+ Open Session Request, RMCP+ Open Session Response 
The RMCP+ Open Session request and response messages are used to enable a remote console to discover 
what Cipher Suite(s) can be used for establishing a session at a requested maximum privilege level. These 
messages are also used for transferring the sessions IDs that the remote console and BMC wish to for the 
session once it’s been activated, and to track each party during the exchange of messages used for 
establishing the session. 


RAKP Message 1, RAKP Message 2 
These messages are used to exchange random number and identification information between the BMC and 
the remote console that are, in effect, mutual challenges for a challenge/response. (Unlike IPMI v1.5, the 
v2.0/RMCP+ challenge/response is symmetric. Le. the remote console and BMC both issues challenges, 
and both need to provide valid responses for the session to be activated.) 


The remote console request (RAKP Message 1) passes a random number and username/privilege 
information that the BMC will later use to ‘sign’ a response message based on key information associated 
with the user and the Authentication Algorithm negotiated in the Open Session Request/Response 
exchange. The BMC responds with RAKP Message 2 and passes a random number and GUID (globally 
unique ID) for the managed system that the remote console uses according the Authentication Algorithm to 
sign a response back to the BMC. 


RAKP Message 3, RAKP Message 4 
The session activation process is completed by the remote console and BMC exchanging messages that are 
signed according to the Authentication Algorithm that was negotiated, and the parameters that were passed 
in the earlier messages. RAKP Message 3 is the signed message from the remote console to the BMC. 
After receiving RAKP Message 3, the BMC returns RAKP Message 4 - a signed message from BMC to 
the remote console. 


The RMCP+ and RAKP Messages are specified in detail later in this section. 


13.16 RMCP+ Session Termination 


The following actions can terminate a session: 
e The Close Session command 
e Session Inactivity Timeout (See Per IPMI v1.5 section 6.11.13, Session Inactivity Timeouts) 


Terminating a session causes any payloads that were activated under that session to be automatically deactivated. 
Terminating one session will not cause other sessions to terminate. If multiple sessions are opened by a remote 
console they will need to be terminated individually. 


13.17 RMCP+ Open Session Request 


The remote console sends this RMCP+ message to the managed system to open a protected session. The client 
responds with an RMCP+ Open Session Response message. Following the Remote Console Session ID field, this 
message contains one or more Authentication Payload proposals, one or more Integrity Payload proposals, and 
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found a Cipher Suite that matches up with the one or more combinations of the algorithm proposals. 


The following table defines the RMCP+ packet fields for this message. 


IPMI Session Header 


IPMI Payload 


Table 13-, RMCP+ Open Session Request 


byte 


data field 


Payload Type = RMCP+ Open Session Request 
Session ID = 00 00 00 00h 
Session Sequence Number = 00 00 00 00h 


1 Message Tag - Selected by remote console. Used by remote console to help match 
responses up with requests. In this case, the corresponding Open Session Response 
that is returned by the BMC. The BMC can use this value to help differentiate retried 
messages from new messages from the remote console. 

2 Requested Maximum Privilege Level (Role) 

[7:4]- Reserved for future definition by this specification, set to Oh 
[3:0] - Requested Maximum Privilege Level (Role). 
Oh = Highest level matching proposed algorithms. 
BMC will pick the Cipher Suite returned in the RMCP+ Open Session 
Response by checking the algorithms proposed in the RMCP+ Open 
Session Request against the Cipher Suites available for each privilege 
level, starting with the “OEM Proprietary level” and progressing to lower 
privilege levels until a match is found. The resultant match results in an 
‘effective’ maximum privilege level for the session. The resultant level is 
returned in the RMCP+ Open Session Response. 
ih= CALLBACK level 
2h= USER level 
3h = OPERATOR level 
4h = ADMINISTRATOR level 
5h = OEM Proprietary level 
3:4 | reserved - write as 00 00h 
5:8 | Remote Console Session ID. Selected by the remote console to identify packets that 
are received for the given session by the remote console 
9:16 | Authentication Payload. Identifies the authentication type that the managed system 
wants to use for the session. 
byte 1 - Payload Type 
00h = authentication algorithm 
byte 2:3 - reserved = 0000h 
byte 4 - Payload Length in bytes (1-based). The total length in bytes of the payload 
including the header (= 08h for this specification). 
00h = Null field (“wildcard”). BMC picks algorithm based on Requested Maximum 
Privilege Level and that matches with the proposed Integrity and Confidentiality 
payloads. If the Requested Maximum Privilege Level is ‘unspecified’ the BMC 
picks algorithm based on the Integrity and Confidentiality algorithm proposals 
starting from the highest privilege level until a match is found. 
byte 5 - Authentication Algorithm 
[7:6]- reserved 
[5:0] - ` Authentication Algorithm (See Table 13-, Authentication Algorithm Numbers) 
byte 6:8 - reserved 
17:24 | Integrity Payload. Identifies the integrity type that the managed system wants to use for 


the session. 

byte 1 - Payload Type 

Oth = integrity algorithm 

byte 2:3 - reserved = 0000h 

byte 4 - Payload Length in bytes (1-based). The total length in bytes of the payload 

including the header (= 08h for this specification). 

00h = Null field (“wildcard”). BMC picks algorithm based on Requested Maximum 
Privilege Level and that matches with the proposed Authentication and 
Confidentiality payloads. If the Requested Maximum Privilege Level is 
‘unspecified’ the BMC picks algorithm based on the Authentication and 
Confidentiality algorithm proposals starting from the highest privilege level until 
a match is found. 
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byte 5 - Integrity Algorithm 
[7:6]- reserved 
[5:0] - Integrity Algorithm (See Table 13-, Integrity Algorithm Numbers) 
byte 6:8 - reserved 
25:32 | Confidentiality Payload. Defined confidentiality algorithms are: 
byte 1 - Payload Type 
02h = confidentiality algorithm 
byte 2:3 - reserved = 0000h 
byte 4 - Payload Length in bytes (1-based). The total length in bytes of the payload 
including the header (= 08h for this specification). 
00h = Null field (“wildcard”). BMC picks algorithm based on Requested Maximum 
Privilege Level and that matches with the proposed Authentication and Integrity 
payloads. If the Requested Maximum Privilege Level is ‘unspecified’ the BMC 
picks algorithm based on the Authentication and Integrity algorithm proposals 
starting from the highest privilege level until a match is found. 
byte 5 - Confidentiality Algorithm 
7:6]- reserved 
[5:0] - | Confidentiality Algorithm (See Table 13-, Confidentiality Algorithm Numbers) 


byte 6:8 - reserved 


13.18 RMCP+ Open Session Response 


A managed system sends this RMCP+ message to the management console in response to an RMCP+ Open 
Session Request message. Following the Status Code, Mgmt Console and Managed System Session ID fields, this 
message contains a single Authentication payload, a single Integrity payload, and a single Confidentiality payload. 
These payloads represent the proposals that the managed system selected from the list offered by the management 
console. 


The following table defines the RMCP+ packet fields for this message. 


Table 13-, RMCP+ Open Session Response 
byte data field 


IPMI Session Payload Type = RMCP+ Open Session Response 
Header Session ID = 00 00 00 00h 


Session Sequence Number = 00_00_00_00h 
IPMI Payload 1 Message Tag - The BMC returns the Message Tag value that was passed by the remote 
console in the Open Session Request message. 

2 RMCP+ Status Code - Identifies the status of the previous message. If the previous message 
generated an error, then only the Status Code, Reserved, and Remote Console Session ID 
fields are returned. See Table 13-, RMCP+ and RAKP Message Status Codes. The session 
establishment in progress is discarded at the BMC, and the remote console will need to start 
over with a new Open Session Request message. (Since the BMC has not yet delivered a 
Managed System Session ID to the remote console, it shouldn’t be carrying any state 
information from the prior Open Session Request, but if it has, that state should be 
discarded.) 

3 Maximum Privilege Level (Role) - Indicates the Maximum Privilege Level allowed for the 
session based on the security algorithms that were proposed in the RMCP+ Open Session 
Request. 

[7:4] - Reserved for future definition by this specification, set to Oh 
[3:0] - Requested Maximum Privilege Level (Role). 
Oh = unspecified (returned with error completion code). 
1h = CALLBACK level 
2h = USER level 
3h = OPERATOR level 
4h = ADMINISTRATOR level 
5h = OEM Proprietary level 
4 reserved - write as 00h 
5:8 Remote Console Session ID The Remote Console Session ID specified by RMCP+ Open 
Session Request message associated with this response. 
9:12 | Managed System Session ID The Session ID selected by the Managed System for this new 
session. A null Session ID (All O's) is not valid in this context. 


148 


Intelligent Platform Management Interface Specification 


13:20 | Authentication Payload This payload defines the authentication algorithm proposal selected 
by the Managed System to be used for this session (see Table 13-, RMCP+ Open Session 
Request for the definition of this payload). A single algorithm will be returned. The ‘Null field’ 


is not allowed. 


Integrity Payload This payload defines the integrity algorithm proposal selected by the 
Managed System to be used for this session (see Table 13-, RMCP+ Open Session Request 
for the definition of this payload). A single algorithm will be returned. The ‘Null field’ is not 
allowed. 


Confidentiality Payload This payload defines the confidentiality algorithm proposal selected by 
the Managed System to be used for this session (see Table 13-, RMCP+ Open Session 
Request for the definition of this payload). A single algorithm will be returned. The ‘Null field’ 
is not allowed. 


21:28 


29:36 


13.19 RAKP Messages 


RAKP Messages are transferred in the payload portion of an IPMI over LAN packet with a Format field set to 
“RMCP+”. The Payload Type field indicates which RAKP message is held in the IPMI Payload portion of the 
packet. 


13.20 RAKP Message 1 


A remote console sends this RAKP message to the managed system to begin the session authentication process. 
The remote console selects a Remote Console Random Number, a Maximum Requested Privilege Level (Role), 

and an optional User Name and sends them to the managed system along with the Managed System Session ID 
specified by the client on the previous RMCP+ Open Session Response. 


Upon receiving RAKP Message 1, the managed system verifies that the message contains an active Managed 
System Session ID and that a session can be created using the given user information and security algorithm 
proposal. The managed system responds with an RAKP Message 2. 
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The format of the IPMI Session Header, Payload, and Session Trailer for the RAKP Message I is shown in the 


following table. 


IPMI Session 
Header 


IPMI Payload 
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Table 13-, RAKP Message 1 


byte data field 
Payload Type = RAKP Message 1 
Session ID = 00_00_00_00h 
Session Sequence Number = 00_00_00_00h 

1 Message Tag - Selected by remote console. Used by remote console to help match 

responses up with requests. In this case, the corresponding RAKP Message 2 that is returned 
by the BMC. The BMC can use this value to help differentiate retried messages from new 
messages from the remote console. 

DA reserved - write as 00_00_00h 

5:8 Managed System Session ID 
The Managed System’s Session ID for this session, returned by the Managed System on the 
previous RMCP+ Open Session Response message. 

9:24 Remote Console Random Number 
Random number selected by the Remote Console 

25 Requested Maximum Privilege Level (Role) 
[7:5] - Reserved for future definition by this specification, set to 000b 
[4]- Ob- Username/Privilege lookup. Both the Requested Privilege Level and User 

Name are used to look up password/key. The BMC will search the user entries 

starting with USER ID 1 and use the first entry that matches the specified user 

name and has a Maximum Privilege Level that matches the Requested 

Privilege Level. This can be used in combination with ‘null’ user names to 

enable a “role only” login with a password that is just associated with the 

requested privilege level. 
1b = Name-only lookup. User Name alone is used to look up password/key. Privilege 

Level field acts as a ‘Maximum Requested Privilege Level’ as in IPMI v1.5. The 

rules for privilege level handling are summarized as follows: 

e |f the Requested Privilege Level is greater than the privilege limit for the 
channel/user, the user will be allowed to connect but will be restricted to the 
channel/user privilege limit that was configured for the user. 

e |f the Requested Privilege Level is less than the channel/user privilege limit, 
the user will be allowed to connect and Request Privilege Level will become 
the effective privilege limit for the user. Le the user will not be able to raise 
their privilege level higher than the Requested Privilege Level. 

[3:0] - Requested Maximum Privilege Level 
Oh = reserved 
1h = CALLBACK level 
2h = USER level 
3h = OPERATOR level 
4h = ADMINISTRATOR level 
5h = OEM Proprietary level 
26:27 | reserved - write as 00_00h 
28 User Name Length 
00h No name present 
O1h-10h Name length 
11h-FFh Reserved for future definition by this specification 
(29:44) | User Name ASCII character Name that the user at the Remote Console wishes to assume for 


this session. No NULL characters (00h) are allowed in the name. Sixteen-bytes, max. 
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13.21 RAKP Message 2 


The managed system sends this RAKP message to a remote console in response to the receipt of an RAKP 
Message 1. Once RAKP Message I has been validated the managed system selects a Managed System Random 
Number and computes a Key Exchange Authentication Code over the values specified by the RAKP algorithm. 
The managed system sends those values along with the Managed System Globally Unique ID (GUID) and the 


Remote Console Session ID (sent by the console on the previous RMCP+ Open Session Request) to the remote 
console. 


Upon receiving RAKP Message 2, the remote console verifies that the Remote Console Session ID is active and 
that the Managed System GUID matches the managed system that the remote console has associated with the 


session. The remote console then validates the Key Exchange Authentication Code and responds with an RAKP 
Message 3. 


The format of an RAKP Message 2 message’s Data section is as follows: 


Table 13-, RAKP Message 2 
byte data field 
IPMI Session Header Payload Type = RAKP Message 2 
Session ID = 00 00 00 00h 
Session Sequence Number = 00 00 00 00h 


IPMI Payload 1 Message Tag - The BMC returns the Message Tag value that was passed by the 
remote console in RAKP Message 1. 


2 RMCP+ Status Code - Identifies the status of the previous message. If the previous 
message generated an error, then only the Completion Code, Reserved, and 
Remote Console Session ID fields are returned. If the Remote Console Session ID 
field is indeterminate (as would be the case if the Managed System Session ID in 
RAKP Message 1 were invalid) then the Remote Console Session ID field will be 
set to all zeros. 


On error, the remote console can attempt to correct the error and send a new RAKP 
Message 1. Note that the remote console must change the Message Tag value to 
ensure the BMC sees the message as a new message and not as a retry. 


See Table 13-, RMCP+ and RAKP Message Status Codes for the status codes 
defined for this message. 


3:4 Reserved - write as 00 00h. 


5:8 Remote Console Session ID - The Remote Console Session ID specified by the 
RMCP+ Open Session Request message associated with this response. 

9:24 Managed System Random Number - Random number selected by the managed 
system. 


25:40 Managed System GUID - The Globally Unique ID (GUID) of the Managed System. 
This value is typically specified by the client system’s SMBIOS implementation. See 
22.14, Get System GUID Command, for additional information. 


41:N Key Exchange Authentication Code 


An integrity check value over the relevant items specified by the RAKP algorithm for 
RAKP Message 2. The size of this field depends on the specific Authentication 
Algorithm (e.g. for RAKP-HMAC-SHA1 the Authentication Algorithm would be 
HMAC using SHA1 to generate a 20-byte authentication code) that was identified in 
the RMCP+ Open Session Response. This field may be O-bytes (absent) for some 
algorithms (e.g. RAKP-none). 
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13.22 RAKP Message 3 


A remote console sends this RAKP message to a managed system in response to the receipt of an RAKP Message 
2. Once it validates RAKP Message 2, the remote console creates a Session Integrity Key using the values 
specified by the RAKP algorithm. The remote console then computes an Integrity Check Value over the values 
specified by the RAKP algorithm, and sends that along with the Managed System Session ID (sent by the 
managed system on the previous RMCP+ Open Session Response message) to the managed system. 


After receiving RAKP Message 3, the managed system verifies that the Managed System Session ID is active and 
then validates the Integrity Check Value. If the Integrity Check Value is valid, the managed system creates a 
Session Integrity Key using the values specified by the RAKP algorithm. With the shared Session Integrity Key in 
place, integrity protected messages can now be exchanged between the remote console and the managed system. 


The format of an RAKP Message 3 message’s Data section is as follows: 
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IPMI Session Header 


IPMI Payload 


byte 


Table 13-, RAKP Message 3 
data field 


Payload Type = RAKP Message 3 
Session ID = 00 00 00 00h 
Session Sequence Number = 00 00 00 00h 


Message Tag - Selected by remote console. Used by remote console to help match 
responses up with requests. In this case, the corresponding RAKP Message 4 that is 
returned by the BMC. The BMC can use this value to help differentiate retried 
messages from new messages from the remote console. 


RMCP+ Status Code Identifies the status of the previous message. If the previous 
message generated an error, then only the Completion Code, Reserved, and 
Managed System Session ID fields are returned. 


If the BMC receives an error from the remote console, it will immediately terminate the 
RAKP exchange in progress, and will not respond with an RAKP Message 4, even if 
the remaining parameters and Key Exchange Authentication code (below) are valid. 
(Terminating the RAKP exchange in progress means that the BMC will require the 
remote console to restart the RAKP authentication process starting with RAKP 
Message 1.) 

See Table 13-, RMCP+ and RAKP Message Status Codes for the status codes 
defined for this message. 


3:4 


Reserved - write as 00 00h. 


5:8 


Managed System Session ID 
The Managed System’s Session ID for this session, returned by the managed system 
on the previous RMCP+ Open Session Response message. 


ON 


Key Exchange Authentication Code 

An integrity check value over the relevant items specified by the RAKP authentication 
algorithm identified in RAKP Message 1 . The size of this field depends on the 
specific Authentication Algorithm. This field may be 0 bytes (absent) for some 
algorithms (e.g. RAKP-none). Note that if the authentication algorithm for the given 
Requested Maximum Privilege Level/Role specifies (e.g. RAKP-none) specifies ‘no 
Authentication Code’ then this field must be absent to be considered a match for the 
algorithm. 
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13.23 RAKP Message 4 


A managed client sends this RAKP message to a management console in response to the receipt of an RAKP 
Message 3. Once RAKP Message 3 has been validated, the managed client computes an Integrity Check Value 
over the values specified by the RAKP algorithm. The managed client then sends the Mgmt Console Session ID 
and the Integrity Check Value to the management console. 


Upon receiving RAKP Message 4, the management console verifies that the Mgmt Console Session ID is active 
and then validates the Integrity Check Value. 


The format of an RAKP Message 4 message’s Data section is as follows: 


IPMI Session Header 


IPMI Payload 


byte 


Table 13-, RAKP Message 4 
data field 


Payload Type = RAKP Message 4 
Session ID = 00 00 00 00h 
Session Sequence Number = 00 00 00 00h 


Message Tag - The BMC returns the Message Tag value that was passed by the 
remote console in RAKP Message 3. 


RMCP+ Status Code - Identifies the status of the previous message. If the 
previous message generated an error, then only the Status Code, 
Reserved, and Management Console Session ID fields are returned. See 
2.1.3.6.1 for the status codes defined for this message. 


3:4 


Reserved - Reserved for future definition by this specification set to 
000000h. 


5:8 


Mgmt Console Session ID The Mgmt Console Session ID specified by the 
RMCP+ Open Session Request (83h) message associated with this 
response. 


9:N 


Integrity Check Value An integrity check value over the relevant items 
specified by the RAKP authentication algorithm that was identified in RAKP 
Message 1. The size of this field depends on the specific authentication 
algorithm. (For example, the RAKP-HMAC-SHA1 specifies that an HMAC- 
SHA1-96 algorithm be used for calculating this field. See Section 13.28, 
Authentication, Integrity, and Confidentiality Algorithm Numbers for info on 
the algorithm to be used for this field.) This field may be 0 bytes (absent) for 
some authentication algorithms (e.g. RAKP-none) 
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13.24 RMCP+ and RAKP Message Status Codes 


The table below lists the status codes for specific RMCP+ and RAKP messages. 


Table 13-, RMCP+ and RAKP Message Status Codes 


Status Description Message 
Code 
RMCP+ 
Open 
Session RAKP RAKP RAKP 
Response Msg 2 Msg 3 Msg 4 

00h No errors x x x 
Oth Insufficient resources to create a x x x 

session 
02h Invalid Session ID x x x x 
03h Invalid payload type x 
04h Invalid authentication algorithm X 
05h Invalid integrity algorithm x 
06h No matching authentication payload x 
07h No matching integrity payload x 
08h Inactive Session ID X x x 
09h Invalid role x x 
OAh Unauthorized role or privilege level x 

requested 
OBh Insufficient resources to create a x 

session at the requested role 
OCh Invalid name length x 
ODh Unauthorized name x 
OEh Unauthorized GUID. (GUID that BMC x 

submitted in RAKP Message 2 was not 

accepted by remote console) 
DER Invalid integrity check value X x 
10h Invalid confidentiality algorithm x 
11h No Cipher Suite match with proposed x 

security algorithms 
12h Illegal or unrecognized parameter X X X x 

13h-FFh Reserved for future definition by this 
specification 


13.25 Differences between v1.5 and v2.0/RMCP+ Sessions 


The following presents an overview of some notable differences as well as similarities between IPMI v1.5 and 
RMCP user setup and session activation mechanisms: 
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IPMI v1.5 had a hook that would allow packets under a session to have different authentication 
signatures than the type of signature that was negotiated to open the session. This hook was to include 
a ‘Authentication Type’ field that specified the type of authentication on a per-packet basis. This 
capability was not used in the specification. Thus, to simplify things a packet can only have two types 
of authentication: the type of authentication selected in the “Open Session” command or “none” - thus 
the ‘Authentication Type’ field is deleted and instead the presence or absence of the “Integrity Data” 
field is used to indicate whether a given packet in the session is authenticated or not. 


IPMI v1.5 uses a single challenge-response mechanism for user authentication (the BMC issues a 
challenge, and the remote console must issue a response). IPMI v2.0/RMCP+ uses a symmetric 
challenge where both the BMC and Remote Console issue challenges, and both the BMC and Remote 
Console must return correct responses for the session to be activated. 
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e ASF 2.0 authentication defined ‘Roles’ such as User and Administrator, where a key (password) was 
associated with each role. IPMI v1.5 authentication associated a key with each User Name where a 
‘privilege level’ (such as User or Administrator) was configured for each user name. These two 
approaches are both available in IPMI v2.0/RMCP+. The BMC can be configured with ‘null’ user 
names, whereby key lookup is done based on ‘privilege level only’, or with non-null user names, 
where the key lookup for the session is determined according to the user name. 


e IPMI v1.5 uses a single, common Session ID that identifies the session to the BMC and remote 
console. IPMI v2.0/RMCP+ allows the BMC and remote console to both pick Session IDs that identify 
their incoming traffic for the session. 


e IPMI v1.5 uses a single key (the user key/password) that is used both for authentication and in integrity 
(AuthCode) calculations. IPMI v2.0/RMCP+ can be configured to use a single key (*one-key”) login 
where the user key is used both for authentication and to generate a Session Integrity Key that is used 
in integrity (AuthCode) calculations, or a “two-key” login where the user key is used for 
authentication, and a separate “BMC key”, KG, is used to create the Session Integrity Key that is used 
in integrity (AuthCode) calculations. 


13.26 IPMI v2.0 RMCP+ Payload Types 


The Payload Type field in the IPMI v2.0/RMCP+ packet carries a Payload Type Number that identifies what type 
of payload field is being carried in that particular packet. 


The Payload Type Numbers (also referred to as payload types) are classified into three main categories: Standard 
Payload Types - used to identify payloads that are specified by the IPMI specifications, Session Setup Payload 
Types - used to identify payloads that are for session setup messages specified by the IPMI specifications, and 
OEM Payload Types that are used to identify payloads that are specified by a given OEM. 


The following table lists the assignment and ranges of the Payload Type Numbers. The complete identification of 
an OEM Payload is given by the combination of a three-byte IANA ID for the OEM, a reserved byte, plus a two- 
byte OEM Payload ID that is assigned and defined by the given OEM. These can either be carried explicitly in 
each packet (adding six bytes of overhead) or an application can elect to use an OEM Payload Type Handle. The 
OEM Payload Type Handle in the Payload Type provides a value that represents a particular OEM IANA and 
OEM Payload ID on a system. The Get Channel Payload Support command is used discover what OEM Payloads 
(if any) are used on the managed system, and to associate the OEM Payload Type number with the OEM IANA 
ID and Payload ID. 


OEM Payload Handle assignments can vary from system to system. For example, “OEMO” on one system may 
not correspond to the same type of OEM Payload as “OEMO” on another system. Software that uses OEM ayload 
Handles must not assume that a given OEM Payload Handle number will correspond to a particular OEM IANA 
and Payload ID combination across multiple systems. Software must use the Get Channel Payload Support 
command to discover the relationship. 


Associated with each payload type is a format version number that provides information on the backward 
compatibility with different versions of the payload type. See Section 24.9, Get Channel Payload Version 
Command, for more information. 


13.27 Payloads and Payload Type Numbers 


Payload Type Numbers are used in the “payload type” field of an IPMI v2.0/RMCP+ packet to identify what’s 
being carried in the data portion of the packet. This data can be categorized into the following types of content: 
Standard payload types that specify commands and data content for messages and protocols defined in this 
specification. Session Setup payload types that are used for messages for session startup and remote access 
authentication algoritihms defined in this specification, and OEM Payload Type Handles that are used to identify 
OEM-specified data that is carried in an IPMI v2.0/RMCP+ packet. 


155 


Intelligent Platform Management Interface Specification 


The Get Channel Payload Support command returns which standard payload type numbers and OEM payload 
type handles are available on a given channel of a BMC. 


13.27.1 IPMI Message Payloads and IPMI Commands 


IPMI Message Payloads are always accepted over any IPMI session, because they are used for IPMI commands 
that are used for managing sessions. Thus, the IPMI payload type does not need to be explicitly enabled, and 
cannot be disabled via the Activate and Deactivate Payload commands, respectively. 


However, while the IPMI Message payload type is accepted, specific IPMI commands may not be accepted. For 
example, the Set User Access command determines whether a given user can execute IPMI commands that are 
not specific to managing a session or to specific to a particular payload type. For example, if IPMI Messaging is 
disabled for a user, but the user is enabled for activating the SOL payload type, then IPMI commands associated 
with SOL and session management, such as Get SOL Configuration Parameters and Close Session are 
available, but generic IPMI commands such as Get SEL Time are unavailable on the SOL Payload session. 


The following commands remain available for payloads if IPMI Messaging Payload type, or IPMI Messaging, 
is disabled for the channel: 


Deactivate Payload, Suspend/Resume Payload Encryption (as defined for given payload), Get Payload 
Activation Status, Get Channel Payload Version Command, Get Channel OEM Payload Info (if 
implemented), Set Session Privilege Level, and Close Session. 


In addition, the IPMI commands that are available before a session is established, and commands that are 
required to activate a session, such as Get System GUID, and Activate Session, also remain available. These 
commands are identified with the notation “p” in Table G-1, Command Number Assignments and Privilege 
Levels. Note some of these commands are not supported for IPMI v1.5/RMCP connections, in which case they 


will be unavailable. 


13.27.2 OEM Payload Type Handles 


OEM Payload Type Handles are a specific numeric range of values that can be carried in the payload type field 
of an IPMI v2.0/RMCP+ packet. These values do not explicitly specify a type of OEM payload, but instead are 
“handles” that are used to identify and access an OEM payload type on a given implementation or instance of a 
BMC. OEM Payload Types are actually specified by the combination of an OEM IANA and an OEM-specified 
Payload ID number. The OEM Payload Type Handle can be used in the Get Channel OEM Payload Info 
command can be used to look up the OEM IANA and OEM Payload ID associated with a particular payload 
type number. 
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13.27.3 Payload Type Numbers 
The following table defines the payload type numbers and ranges for OEM Payload Type Handles. 


Table 13-, Payload Type Numbers 


major format minor format 
number!!! | type version version 

Standard Payload Types 

Oh IPMI Message th Oh 

ih SOL (serial over LAN) th Oh 

2h OEM Explicit OEM specified OEM specified 
(When this payload type appears in the network according to OEM | according to OEM 
header, it indicates that the packet includes explicit | [ANA and OEM IANA and OEM 
OEM IANA and OEM Payload ID fields that identify | Payload ID. Payload ID. 
the payload type, instead of using an OEM Payload 
Type Handle to identify the type of payload 
contained in the packet. When used, this option 
adds 6 bytes to the overhead of the packet.) 
Session Setup Payload Types 

10h RMCP+ Open Session Request th Oh 

Tih RMCP+ Open Session Response th Oh 

12h RAKP Message 1 th Oh 

13h RAKP Message 2 th Oh 

14h RAKP Message 3 th Oh 

15h RAKP Message 4 th Oh 
OEM Payload Type Handles 

20h-27h Handle values for OEM payloads OEMO through OEM specified OEM specified 
OEM7, respectively. according to OEM | according to OEM 
IANA and OEM IANA and OEM 
Payload ID. Payload ID. 
all other reserved 


1. The payload type number is a 6-bits (00h-3Fh). 


13.28 Authentication, Integrity, and Confidentiality Algorithm 
Numbers 


The Authentication Algorithm Number specifies the type of authentication “handshake” process that is used and 
identifies any particular variations of hashing or signature algorithm that is used as part of the process. 


Table 13-, Authentication Algorithm Numbers 


Mandatory / 

number* | type Optional" 

00h RAKP-none M 

Oth RAKP-HMAC-SHA1 M 

02h RAKP-HMAC-MD5 O 

03h RAKP-HMAC-SHA256 O 
COh-FFh | OEM oO 
all other reserved 


1 Mandatory/Optional is with respect to BMC support. It is recommended that remote consoles support all specified algorithms in 


order to support maximum number of BMC implementations. 


The number range is limited to six (6) bits (00h-3Fh) 
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13.28.1 RAKP-HMAC-SHA1 Authentication Algorithm 


RAKP-HMAC-SHAI specifies the use of RAKP messages for the key exchange portion of establishing the 
session, and that HMAC-SHA I (per [RFC2104]) is used to create 20-byte Key Exchange Authentication Code 
fields in RAKP Message 2 and RAKP Message 3. HMAC-SHA1-96 (per [RFC2404]) is used for generating a 
12-byte Integrity Check Value field for RAKP Message 4. 


13.28.1b RAKP-HMAC-SHA256 Authentication Algorithm 


RAKP-HMAC-SHA256 specifies the use of RAKP messages for the key exchange portion of establishing the 
session, and that HMAC-SHA256 (per [FIPS 180-2] and [RFC4634] and is used to create a 32-byte Key 
Exchange Authentication Code fields in RAKP Message 2 and RAKP Message 3. HMAC-SHA256-128 (per 
[RFC4868]) is used for generating a /6-byte Integrity Check Value field for RAKP Message 4. 


13.28.2 RAKP-none Authentication Algorithm 


RAKP-none uses the same steps and messages as RAKP-HMAC-SHAI, but the Key Exchange Authentication 
Code field in RAKP Message 2 and RAKP Message 3 and the Integrity Check Value field in RAKP Message 4 
are absent since they are not used. RAKP-none does not provide password authentication or RAKP packet level 
data integrity checking. The RAKP steps establish Session IDs and privilege level using only the given 
username/role. A BMC implementation can be configured with a null username that has a null (all 0’s) 
password. A BMC configured this way, and using the RAKP-none Authentication Algorithm, provides a way to 
enable access the BMC without requiring a username and password. 


13.28.3 RAKP-HMAC-MD5 Authentication Algorithm 


This authentication algorithm operates the same way as RAKP-HMAC-SHA1 except that HMAC with MD5 
(per [RFC2104] is used for RAKP authentication operations in place of SHA-1. Thus, the Key Exchange 
Authentication Code fields in RAKP Message 2 and RAKP Message 3 and the Integrity Check Value field in 
RAKP Message 4 are all 16-byte fields (128-bit MD5). Since MD5 requires fewer computational steps than 
SHA-1, this option can be used to offer a quicker session activation, particularly on management controllers that 
have limited computational resources. 


When the SIK and additional keying material (K1, K2, etc.) are generated (per sections 13.31, RMCP+ 
Authenticated Key-Exchange Protocol (RAKP), and 13.32, Generating Additional Keying Material) the MD5 
algorithm is used in the HMAC algorithm, resulting in 16-byte (128-bit) keys. 


13.28.4 Integrity Algorithms 


The Integrity Algorithm Number specifies the algorithm used to generate the contents for the AuthCode 
“signature” field that accompanies authenticated IPMI v2.0/RMCP+ messages once the session has been 
established. 


Unless otherwise specified, the integrity algorithm is applied to the packet data starting with the 
AuthType/Format field up to and including the field that immediately precedes the AuthCode field itself. 


When using the integrity algorithms with the Get AuthCode command, the integrity algorithm is applied to the 
data passed in the Get AuthCode command, using key information selected by the given User ID and Channel 
number. If an SIK needs to be calculated, it is calculated using the user key (password) information as descibed 
for ‘one-key’ logins. 


none. If the Integrity Algorithm is none the AuthCode value is not calculated and the AuthCode field in the 
message is not present (zero bytes). 


HMAC-SHA1-96, HMAC-SHA256-128, and HMAC-MD5-128 take the Session Integrity Key and use it to 
generate K1. K1 is then used as the key for use in HMAC to produce the AuthCode field. For “two-key” 
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logins, 160-bit key KG is used in the creation of SIK. For “one-key” logins, the user’s key (password) is 
used in place of KG. To maintain a comparable level of authentication, it is recommended that a full 160-bit 
user key be used when “one-key” logins are enabled for IPMI v2.0/RMCP+. 


When the HMAC-SHA1-96 Integrity Algorithm is used the resulting AuthCode field is 12 bytes (96 bits). 


When the HMAC-SHA256-128 and HMAC-MD5-128 Integrity Algorithms are used the resulting AuthCode 
field is 16-bytes (128 bits). 


MD5-128 uses a straight MDS signature with the user’s key information appended at the beginning and the end 


of the packet data to calculate the AuthCode field as: 
AuthCode = MD5(password + AuthType/Format + ... + Next Header + password) 


The MD5-128 Integrity Algorithm does not use K1 or HMAC. This results in significantly fewer 
computation steps than the HMAC- algorithms, potentially providing significantly improved throughput 
performance on certain management controllers. However, this algorithm also delivers less protection 
against password and replay attacks than the HMAC based options and thus should only be used when 
operating in a trusted environment where data integrity checking is desired but other attacks are not a 
concern. 


When the MD5-128 Integrity Algorithm is used the resulting AuthCode field is 16 bytes (128 bits). 


Table 13-, Integrity Algorithm Numbers 


Mandatory / 

number* | type Optional 

00h none M 

Oth HMAC-SHA1-96 M 

02h HMAC-MD5-128 O 

03h MD5-128 O 

04h HMAC-SHA256-128 O 
COh-FFh OEM O 

all other reserved 


* The number range is limited to six (6) bits (00h-3Fh) 


13.28.5 Confidentiality (Encryption) Algorithms 


The Confidentiality Algorithm Number specifies the encryption/decryption algorithm field that is used for 
encrypted payload data under the session. The ‘encrypted’ bit in the payload type field being set identifies 
packets with payloads that include data that is encrypted per this specification. When payload data is encrypted, 
there may be additional “Confidentiality Header” and/or “Confidentiality Trailer” fields that are included within 
the payload. The size and definition of those fields is specific to the particular confidentiality algorithm. 


Table 13-, Confidentiality Algorithm Numbers 


Mandatory / 
number* | type Optional 
00h none 
Oth AES-CBC-128 M 
(See Section 13.29, AES-CBC-128 Encrypted Payload Format, for more information) 
02h xRC4-128 EN 
(See Section 13.30, xRC4 Encrypted Payload Format, for more information) 
03h xRC4-40 O 
(See Section 13.30, xRC4 Encrypted Payload Format, for more information) 
30-3Fh OEM O 
all other reserved - 


* The number range is limited to six (6) bits (00h-3Fh) 
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13.29 AES-CBC-128 Encrypted Payload Format 


The following table summarizes the contents of the IPMI Payload when AES-CBC encryption is used. 


Table 13-, AES-CBC Encrypted Payload Fields 


Field Size Sub field Description 
Confidentiality 16 Initialization Vector For the AES algorithm in CBC mode, this field must be 
Header a 16-byte random value generated uniquely for each 


message (packet). 


Payload Data variable | Payload Data 
Confidentiality | variable | Confidentiality Pad Added to the Data field to be encrypted (including the 
Trailer Confidentiality Pad Length field) so that they have a 
length that is a multiple of the block size of algorithm 
being used. For the AES algorithm, the block size is 16 
bytes. 

1 Confidentiality Pad Length | Defines the number of Confidentiality Pad bytes present 
in the message. For the AES algorithm, this number will 
range from 0 to 15 bytes. This field is mandatory. If no 
Confidentiality Pad bytes are required, the 
Confidentiality Pad Length field is set to OOh. If present, 
the value of the first byte of Confidentiality Pad shall be 
one (01h) and all subsequent bytes shall have a 
monotonically increasing value (e.g., 02h, 03h, 04h, 
etc). The receiver, as an additional check for proper 
decryption, shall check the value of each byte of 
Confidentiality Pad. Some messages may not require 
padding if the messages already provide the necessary 
alignment. 


13.29.1 Generating the Initialization Vector 


The initialization vector (IV) should be unpredictable. In particular, for any given plaintext, it must not be 
possible to predict what the next IV will be from the last IV. For AES-CBC-128, the IV is recommended to be a 
16-byte random number generated by a high quality random number generation process. See Section 13.34, 
Random Number Generation. 


13.29.2 Encryption with AES 


AES-128 uses a 128-bit Cipher Key. The Cipher Key is the first 128-bits of key “K2”, K2 is generated from the 
Session Integrity Key (SIK) that was created during session activation. See Section 13.22, RAKP Message 3 and 
Section 13.32, Generating Additional Keying Material. 


Once the Cipher Key has been generated it is used to encrypt the payload data. The payload data is padded to 
make it an integral numbers of blocks in length (a block is 16 bytes for AES). The payload is then encrypted 
one block at a time from the lowest data offset to the highest using Cipher_Key as specified in [AES]. 


13.29.3 CBC (Cipher Block Chaining) 


When CBC is used, before a block of payload data is encrypted it is first exclusive-ORed with the previous 
ciphertext block (or in the case of the first block, with the initialization vector). For AES, this means that the 
each 16-byte block of plaintext payload data is exclusive-ORed with the previous 16-bytes of encrypted data 
before being encrypted. See [MODES] for information on CBC. 


For AEC-CBC-128 encrypted payloads under IPMI v2.0 RMCP+, CBC does not span between packets, it only 
applies to blocks within a packet. Instead, each individual packet is encrypted using a different initialization 
vector. Thus, packets can be decrypted even if an intermediate block is lost. 
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13.30 xRC4 Encrypted Payload Format 


The following applies to both xRC4-128 and xRC4-40 encryption. The difference between the two has to do with 
the size of the key value used to initialize the algorithm. xRC4-128 uses a 128-bit key, and xRC4-40 uses a 40-bit 
key. The generation of the initialization key is described in the last paragraphs of this section. 


Table 13-, xRC4-Encrypted Payload Fields 


Field 
Confidentiality 
Header (not 
encrypted) 


Size 


Sub field 
Data offset 


Description 


This value advances ‘N’ counts for every N-bytes of new 
payload data that is encrypted. The value for the first packet of 
payload data is 0000 0000h. If the first packet contains 12 
bytes of payload data, the data offset for the second packet 
will be 12 (OCh). If the second packet contained 8 bytes of 
payload data, the offset for the third packet will be 20 (14h), 
and so on. The xRC4 algorithm operates in a manner similar 
to a large pseudo-random number generator. Therefore, 
decryption can handle missed packets by advancing the state 
machine by the number of steps to the offset for the data and 
decrypt from that point. 


Initialization Vector 


The Initialization Vector is a 128-bit random number that is 
used in conjunction key information for the session to initialize 
the state machine for xRC4. The Initialization Vector is only 
passed when the xRC4 state machine is initialized or is 
reinitialized (data offset = 0000 0000h). This field is absent 
when the data offset is non-zero. 


Payload Data 


variable 


Payload Data 


Payload data. Encrypted per xRC4 algorithm. 


Confidentiality 
Trailer 


0 


none 


xRC4 does not add use a confidentiality trailer. 


13.30.1 Generating the xRC4 Initialization Vector 


The initialization vector (IV) should be unpredictable. In particular, for any given plaintext, it must not be 
possible to predict what the next IV will be from the last IV. For xRC4, the IV is recommended to be a 16-byte 
random number generated by a high quality random number generation process. See Section 13.34, Random 
Number Generation. 


13.30.2 Initializing the xRC4 State Machines 


There are two xRC4 State Machines that are maintained by the BMC for each xRC4 encrypted payload stream. 
One is used for BMC-to-Remote Console encryption, and the other for Remote Console-to-BMC decryption. 
These shall be referred to as the BMC Encryption and BMC Decryption state machines, respectively. 


The BMC is responsible for creating the Initialization Vector used for initializing the BMC Encryption state 
machine. The remote console is responsible for generating the Initialization Vector for the BMC Decryption 
state machine. The BMC initializes the BMC Encryption state machine for the first encrypted packet it 
generates for the payload, and re-initializes if the remote console requests it via the Suspend/Resume Payload 
Encryption command. 


The BMC initializes the BMC Decryption State machine whenever it receives an encrypted packet that has a 
value of 0000_0000h for the data offset. These packets will contain and Initialization Vector that was generated 
by the remote console. 


The state machines for both the BMC and remote console are initialized using the same algorithm. This 
algorithm creates a key using a combination of the Initialization Vector and the first 128-bits of key “K2” to 
initialize the state table for xRC4. (K2 is generated from the Session Integrity Key (SIK) that was created 
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during session activation. See Section 13.22, RAKP Message 3, and Section 13.32, Generating Additional 
Keying Material) This key is then fed into the xRC4 algorithm to initialize a 256-byte state table. 


The xRC4 key (KRC) is generated using the combination of K2 and the Initialization Vector as: 
KRC = MD5(K2, IV) 
Where: 
MD5= MDS algorithm applied to the concatenation of K2 and IV. 


K2= 128-bit key generated from Session Integrity Key as described in Section 13.22, RAKP 
Message 3, and Section 13.32, Generating Additional Keying Material. 


IV = Initialization Vector. A 128-bit random number 


For xRC4 using a 128-bit key, all bits of KRC are used for initialization. For xRC4 using a 40-bit key, only the 
most significant forty bits of KRC are used. 


13.31 RMCP+ Authenticated Key-Exchange Protocol (RAKP) 


RMCP+ can support a number of different authentication and key exchange protocols during its Creation (session 
activation) phase. For this specification, the mandatory-to-implement authentication and key exchange protocol is 
the RMCP+ Authenticated Key-Exchange Protocol (RAKP). RAKP (defined below) was developed based on the 
Authenticated Key Exchange Protocol (AKEP) defined by Bellare and Rogaway in [BR1]. 


RAKP uses pre-shared symmetric keys to mutually authenticate a remote console to a given managed system and 
to generate pair-wise unique symmetric keying material that can be used with a number of integrity and 
confidentiality algorithms to provide protection for RMCP messages. The use of RAKP with the different 
authentication and integrity algorithms available for IPMI v2.0/RMCP+ is described in 13.28, Authentication, 
Integrity, and Confidentiality Algorithm Numbers. For example, the RAKP-HMAC-SHA1 authentication 
algorithm uses the HMAC-SHA1 integrity algorithm defined in [RFC2104] in the RAKP authentication process, 
and the HMAC-SHA1-96 integrity algorithm defined in [RFC2404] for data integrity. 


6, 


RAKP also supports the concept of remote console user “roles” and optionally “usernames” (e.g. operator “x” or 
administrator “y”), which are established by RAKP when a session is created. 


Examples of behavior that can be controlled include the roles that the managed system can use to establish 
sessions (e.g. operator-only sessions) and the roles and names (optional) allowed to execute each RMCP message 
the managed system might receive during a given session. 


Before a given managed system’s RMCP implementation can become operational, it must be configured with 
various RMCP-related parameters. This includes installing user passwords (keys) and usernames, setting up 
access rights for the individual users, and configuring which Cipher Suites are used for authenticated and/or 
encrypted transfers with the managed system. 


The managed system can be configured with keys for each username, or ‘null’ usernames can be used, in which 
case the key is associated solely with a given privilege level (role). The different user keys are specified using the 
notation K[UID], where UID represents the User ID number that is used in the user-specific configuration 
commands in IPMI. 


The user keys are ‘shared secrets’ between the BMC and the remote console(s). RAKP/RMCP+ does not include 
a secure, confidential mechanism for installing and distributing user keys between BMCs and remote consoles. 
The installation and distribution of user keys can typically be accomplished with a software utility that uses OS- 
provided mechanisms for the secure transfer of keys. If authentication and encryption are available, an ‘Admin’ 
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level user can use IPMI commands such as Set User Password for remotely updating and configuring user key 
and privilege information over an authenticated and confidential session to the BMC. 


An additional key, KG, is used for key generation operations. KG functions essentially as a key for the overall 
BMC, and is thus also referred to as the “BMC Key”. A user needs to know both Kg and a user password (key 
K[unp]) to establish a session, unless the channel is configured with a ‘null’ KG, in which case the user key 
(K[Um) is used in place of KG in the algorithms. The scope of these keys (whether they are shared by multiple 
managed systems and the remote console or are pair-wise unique for each managed system and the remote 
console) is a local policy issue that is determined by the equipment owner at the time of installation, Setting keys 
is described further in Section 13.33, Setting User Passwords and Keys. 


Once this and other necessary RMCP-related data is installed in the managed system and the managed system is 
initialized, the remote console can initiate sessions with the managed system. Following the exchange of RMCP 
Presence Ping/Pong and RMCP+ Open Session Request/Response messages (exchanging Session IDs and 
selecting RAKP for use), the remote console starts the RAKP protocol. First, the remote console selects a random 
number, Ry, a requested role, Roley, a user name length, ULengthm, a user name (optional - denoted by < > 
below), UNamem, and the managed system’s Session ID, SIDc, and sends them to the managed system as 
Message 1. 


Message 1: Remote Console -> Managed System 
SIDc, Rm, Rolem, ULengthm, < UNamem > 
After receiving Message 1, the managed system verifies that the value SID¢ is active and that a session can be 
created using Role, ULengthy, and (optional), UNamey for the given selections for security algorithms. 


If the request is valid, the managed system then selects a random number, Rc, and sends to the remote console as 
Message 2 the values SIDy, Rc, and GUID¢ as well as the HMAC per [RFC2104] of the values (SID, SIDc, 
Ro. Rc, GUIDc, Rolem, ULengthm, < UNamem >) generated using key Krom associated with the given 
username, UNamey, and role, Rolem. 


Message 2: Managed System -» Remote Console 


SIDM, Rc, GUIDc, 
HMACKuID] (SIDM, SIDc, Rm, Rc, GUIDc, Rolem, ULengthm, < UNamem >) 


Where: 
Parameter bytes Name 

SIDm 4 Remote Console Session ID 

SIDc 4 Managed System Session ID 

Ru 16 Remote Console Random_Number 

Rc 16 Managed System Random Number 

GUIDc 16 Managed_System_GUID 

Rolem 1 Requested Privilege Level (Role) (this is the entire byte 
holding the Requested Privilege Level field) 

ULengthm 1 User Name Length byte (number of bytes of UName,, = 0 
for ‘null’ username) 

UNamem var User Name bytes (absent for ‘null’ username) 


Where HMACK up] (SIDm, SIDc, Rm, Rc, GUIDc, Rolem, ULengthm, < UNamem >) represents the value for 
the Key Exchange Authentication Code field in RAKP Message 2. (The HMACKymy notation indicates use of 


the HMAC algorithm per [RFC2104] with the hashing function (e.g. SHA-1, MDS) that is specified for the 
selected authentication algorithm (See 13.28, Authentication, Integrity, and Confidentiality Algorithm Numbers) 
over the concatenation of the indicated fields where K[UID] is the user-specific key that is associated with the 
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given usernname and role. Note that some authentication algorithms may substitute a different algorithm than 
HMAC for generating the Key Exchange Authentication Code.) 


After receiving RAKP Message 2, the remote console verifies that the value SIDy is active and that GUIDc 
matches the managed system that the remote console is expecting to communicate with. The remote console then 
validates the Key Exchange Authentication Code from the message. If the code is valid, the remote console 
creates the Session Integrity Key (SIK) by generating an HMAC per [RFC2104] of the concatenation of Ry, Rc, 
Roley, ULengthy, and (optional) UNamey using 160-bit key Kg (note - no truncation). 


The hashing algorithm used for this HMAC, and the ones following, is specified by the particular authentication 
algorithm being used. (Note that K[UID] is used in place of Kg if ‘one-key’ logins are being used. See 13.28.4, 
Integrity Algorithms) 


SIK = HMACKG (Rm | Rc | Rolem | ULengthm | < UNamem >) 


Then the remote console sends to the managed system as Message 3 the value SIDc and (for the RAKP-HMAC- 
SHA1 algorithm) the HMAC per [RFC2104] of the values (Rc, SID, Roley, ULengthy, < UNamey >) 
generated using key K[UID] selected by the username, UNamem, and role Rolem. 


Message 3: Remote Console -> Managed System 


SIDc, HMACK yD] (Rc, SIDM, Rolem, ULengthm, < UNamem >) 


Where HMACK um (Re, SIDm, Rolem, ULengthm, < UNamem>) represents the value for the Key Exchange 
Authentication Code for RAKP Message 3. After receiving Message 3, the managed system verifies that the value 
SIDc is active and then validates the message authentication code. If the HMAC is valid, the managed system 
creates the SIK by generating an HMAC per [RFC2104] of the concatenation of Ry, Rc, Rolem, ULengthy, and 
(optional) UNamem using 160-bit key Kg (note - no truncation, and that K[UID] is used in place of Kg if “one- 
key’ logins are being used. See /3.28.4, Integrity Algorithms). 


SIK = HMACKG (Rm | Rc | Rolem | ULengthm | < UNamem >) 


The managed system then sends to the management console as Message 4 the values SIDm, and (for the RAKP- 
HMAC-SHA1 algorithm) the HMAC per [RFC2404] of the values (Ry, SIDc, GUIDc) generated using key 
SIK. 


Message 4: Managed System -> Mgmt Console 


SIDm, HMACSIK (Rm, SIDC, GUIDc) 


Where HMACK[umj(Rc, SIDm, Rolem, ULengthm, < UNamem>) represents the value in the Integrity Check 


Value field for RAKP Message 4. After receiving Message 4, the management console verifies that the value 
SIDm is active and then validates the Integrity Check Value. If the value is valid, the management console has 
verification that mutual authentication with the managed system was successful and that the same pair-wise 
unique SIK was successfully generated on both ends of the connection. The management console then transitions 
into the Message Transfer session state (the session is now active and, if authentication or 
authentication/encryption have been enabled, the transfer of authenticated and authenticated/encrypted payloads 
can commence). 


The same RAKP steps are followed for session activation even if the Cipher Suite indicates that there are no 
integrity or encryption algorithms required for the session. 
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13.32 Generating Additional Keying Material 


Because this specification supports both integrity and confidentiality services for a session, RSP needs more 
keying material than can be provided by the session integrity key, SIK, alone. As a result, all keying material for 
the RSP integrity and confidentiality algorithms will be generated by processing a pre-defined set of constants 
using HMAC per [RFC2104], keyed by SIK. 


Ki = HMACsjx (const 1) 
K2 HMACSIK (const 2) 
K3 = HMACSIK (const 3) 


These constants are constructed using a hexadecimal octet value repeated up to the HMAC block size in length 
starting with the constant O1h. This mechanism can be used to derive up to 255 HMAC-block-length pieces of 
keying material from a single SIK. For the mandatory-to-implement integrity and confidentiality algorithms 
defined in this specification, processing the first two (2) constants will generate the require amount of keying 
material. 


Conse. 1 = 0x01010101010101010101 01010101010101010101 
Const 2 = 0x02020202020202020202 02020202020202020202 
Conse > = 0x03030303030303030303 03030303030303030303 


Const 255 = OxFFFFFFFFFFFFFFFFFFFF EEFEEEEEEEFEEEFEEEFE 


13.33 Setting User Passwords and Keys 


User passwords (keys) are set using the Set User Password command. KG is set using the Set Channel Security 
Keys command. The Set Channel Security Keys command allows a different KG to be used on each channel. To 
enable the option of a ‘single key’ login on a given channel, the convention is to configure KG to a reserved value 
of all 0’s. The BMC will then use the value KUID in place of KG. Software that allows a user to login to a BMC by 
entering a username, password, and BMC Key should send values of all 0’s to the BMC when the user does not 
provide explicit values for those fields. The Get Channel Authentication Capabilities command can help a remote 
console application tailor any data entry queries for username and password information to what is in use on a 
given BMC. 


13.34 Random Number Generation 


Algorithms for authentication (data integrity) and confidentiality (for Initialization Vectors) depend on "quality" 
random numbers for their security. Quality in this context means that the numbers must be random in a 
cryptographic sense (i.e., they must be genuinely unpredictable). To ensure that a baseline-level of quality 
random numbers are provided for remote consoles and managed systems, this specification recommends the 
following algorithm be used for random number generation for use in authentication and data integrity algorithms 
if no other higher-quality source of random numbers is available (e.g., a hardware random number generator). 


13.34.1 Random Number Key 


Each BMC is configured with a 160-bit key, Kr, which is unique for each managed system. The Set Channel 
Security Keys command can be used for setting this key. Note that to avoid the possibility of run-time software 
changing this key, the BMC includes an option for the key to be locked so that run-time software cannot change 
the key. 
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13.34.2 Random Number Generator Counters 


The managed system maintains two (2) 32 bit counters, Cp and Cg. Cp is used to count the number of device 
power cycles and its value is saved in non-volatile storage. Cq is used to count the number of random number 
generation requests per power cycle and is volatile. Whenever a new Kr is installed in non-volatile storage, the 
counters are reset to zero (0). Once initialized, Cp is incremented by one (1) after each power cycle and its new 
value is again saved in non-volatile storage. Cq is reset to zero (0) on each power cycle (i.e., its value is not 
saved across power cycles). 


13.34.3 Random Number Generator Operation 


The managed system creates a random number by generating an HMAC per [RFC2104] of the concatenation of 
Cp and Co using key Kr using the SHA1 hash function. The output of this generator is a 160-bit pseudo- 
random number. Uses that require fewer bits can draw the required number of bits from the 160-bit value. Since 
the value is random, it shouldn’t matter which bits are used. Most implementations will simply take either the 
most-significant ‘N’ bits or least-significant, whichever is most convenient. 


Random Number = HMACKR (Cp | Co) 


Cq is incremented by one (1) after each random number generation request. After each power cycle, the value 
of Cq is reset to zero (0) (i.e., its value is not saved across power cycles). If during a given power cycle, Co 
rolls-over to zero, the managed system must increment Cp by one (1) and save its new value back into non- 
volatile storage. 
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14. IPMI Serial/Modem Interface 


This section describes the mechanisms specific to transferring IPMI messages between the BMC and a remote 
management system (remote console) over modem or direct serial connection. It also describes the mechanism that 
support the Serial Port Sharing capability. 


14.1 Serial/Modem Capabilities 


The following is a review of the capabilities that can be provided via an IPMI serial/modem connection: 


IPMI messaging Transmission of IPMI messages between a remote console and the BMC in one of three 
configurable modes: Basic Mode, PPP Mode, and Terminal Mode. 


Dial Paging Ability to generate a numeric page by sending a dial string to a modem. 


TAP Paging Ability to automatically generate a configurable alphanumeric page by automatically 
connecting to a TAP v1.8 -based paging service. 


Dial-out PET Ability to automatically dial up a remote PPP-to-LAN gateway, connect, and place a Platform 
Alerting Event Trap onto the remote LAN. Also known as PPP Alerting. 


Callback Ability for a remote console to trigger the BMC to call the remote console back and establish a 
system management session. There are two types of Call-back: “IPMI” callback, which is 
initiated via an IPMI command to the BMC, and callback using Microsoft’s CBCP (callback 
control protocol). CBCP is an option that is only available in PPP Mode. 


PPP UDP Proxy Option to allow the BMC to function as a low-performance communication bridge to allow 
software to sending and receiving UDP data via a pre-established BMC PPP connection. If the 
call-back option is supported, local management software or BIOS can trigger the BMC to dial 
up the remote console. 


Serial Port Ability to share a serial connector between the BMC’s serial controller and a system serial 
Sharing controller by using circuitry to allow it to be switched between the two. 


14.2 Connection Modes 


The specification for the serial/modem interface supports IPMI Messaging in three possible connection modes. 
Support for Basic Mode is mandatory if serial/modem support is provided. A given implementation can 
implement any number or combination of the other connection mode options. 


Basic Mode This mode uses a simple clear text password to activate a session. IPMI messages are 
encoded and delimited using a simple framing scheme based on ‘escaped’ characters. 
Basic Mode is the most efficient standard operating mode for enabling a remote console 
application to communicate with the BMC using IPMI messages. 


PPP/UDP Mode _ This mode uses the same session and authentication operation as IPMI over LAN. It uses 
PPP as the protocol for establishing a point-to-point communications link over which 
IPMI messages are sent encapsulated in UDP datagrams. This mode incurs significant 
overhead in message size and handshake complexity beyond that required for Basic 
Mode IPMI messaging, but has the advantage of using a widely supported standard. 


Terminal Mode This mode is intended primarily for direct serial connection operation. The mode is 
designed so that a simple terminal or terminal emulator can be used to generate requests 
and get responses from the BMC. The IPMI messages are entered using printable ASCII 
characters. While a user can enable a ‘line edit mode’ and directly enter the codes for an 
IPMI message, the main purpose of this mode is to facilitate the development of scripts 
that work with available terminal emulation programs. 
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Terminal Mode also supports a small number of ASCII Text Commands that can be used 
for operations such as getting a high-level hardware health status for the system, and 
doing system reset and power on/off operations. 


14.2.1 PPP/UDP Proxy Operation 


The BMC can support a mode that allows local system software (e.g. BIOS) to send and receive UDP 
datagrams via the BMC connection to the remote console. This operation is supported using two special 
message buffers associated with the channel: the PPP UDP Proxy Transmit Buffer and the PPP UDP Proxy 
Receive Buffer. 


When PPP/UDP Proxy Operation is supported (and enabled) the BMC will check the destination port address 
used in incoming UDP datagrams. After removing any data escaping and checking the FCS, the BMC will 
check the destination port address in the UDP packet. If the packet is not addressed to either the primary or 
secondary RMCP Port addresses, the BMC will place the contents the packet into the PPP UDP Proxy Receive 
Buffer (assuming the packet fits, and the buffer is already empty). Otherwise, the packet will be silently 
discarded. 


When sending messages to the remote console, local software loads the PPP UDP Proxy Transmit Buffer with 
the contents for the UDP message and then directs the BMC to deliver that message as a UDP datagram from 
the given serial/modem channel. The BMC fills in remaining data for the UDP and IP Header according to data 
passed in the Send PPP UDP Proxy Packet command and from the LAN Configuration parameters and then 
transmits the packet. 


PPP/UDP Proxy Operation is only specified for execution via the BMC system interface. This capability is 
OPTIONAL for serial/modem channels that support PPP mode. 


14.2.2 Asynchronous Communication Parameters 


The asynchronous communication parameters consist of elements such as bit rate, type of handshake, parity, 
and other settings related to the configuration of the BMC’s serial controller. These setting are configured via 
the serial/modem configuration parameters. 


The number of different sets of parameters for a given channel depends on which messaging and alerting 
features are implemented: 


e There is one set for use by IPMI Messaging (Basic Mode, PPP Mode, or Terminal Mode) for the entire 
channel. 


e There is one set of asynchronous communication parameters for each Alert or Callback Destination 
supported by a channel, used according to the Alert Type (Dial Page, TAP Page, PPP Alert, Callback). 


14.2.3 Serial Port Sharing 
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could be accomplished using a multiplexer to switch serial connector signals between the BMC and the 
baseboard serial controller. 


Figure 14- is referred to as a logical diagram because this specification does not require a particular physical 
implementation as long as the commands function as described in this specification. 


Figure 14-, Serial Port Sharing Logical Diagram 
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14.2.4 Serial Port Switching 


The following can cause a switch of the serial port: 


Table 14-, Serial Port Switching Triggers 


From - To Cause disablel'! | Notes 
BMC to Baseboard IPMI Set Serial/Modem Mux command. yes 
Microsoft VT100 'Exit Exit UPS, ASIC or yes <ESC>Q 
Service Processor' Escape sequence. (see 
ref: [MSVT]). Per [MSVT] the BMC should 
immediately acknowledge the switch to 
baseboard by returning <ESC>* 
Baseboard to BMC IPMI Set Serial/Modem Mux command. no 
Microsoft VT 100 ‘Invoke ASIC/Service yes <ESC>( 
Processor’ Escape sequence (see ref: Pattern is also used for 
[MSVT]) Connection Mode Auto-detect 
capability. See 14.2.9, 
Connection Mode Auto-detect. 
Detection of basic mode Get Channel yes Requires Basic Mode to be 
Authentication Capabilities request enabled. Pattern is also used for 
Connection Mode Auto-detect 
capability. See 14.2.9, 
Connection Mode Auto-detect. 
Detection of leading bytes in a PPP IPv4- yes Requires PPP mode to be 
UDP Packet addressed to BMC's IP enabled. Pattern is also used for 
address and RMCP primary or secondary Connection Mode Auto-detect 
port, ending at the RMCP message class capability. See 14.2.9, 
field. Connection Mode Auto-detect. 
PPP Protocol = Internet Protocol (e.g. 
0021h) 
Packet = IPv4 UDP Datagram 
IP Address = BMC IP Address 
Port = Primary or Secondary 
RMCP port, as set in the 
serial/modem configuration 
parameters 
Initial packet data = RMCP v1.0 header 
with message class field = 
IPMI 
RI Signal yes In Modem Connect mode only. 
See 14.2.11, Modem Activation 
for more information. 
DCD Signal yes Used to cause a mux switch to 


BMC when in Direct Connect 
mode. 


1. This indicates whether a configuration option to disable switching on this action exists. Note that switching may also be 


disabled as part of the operation of some access modes, such as ‘Pre-boot Only’. 


14.2.5 Access Modes 


BMC channels used for serial/modem access can be configured for several Access Modes using the Set Channel 
Access command. The command determines which states of system operation (e.g. pre-boot) the channel can be 


used for BMC communication. Refer to section 6.6, Channel Access Modes for more information. 


14.2.6 Console Redirection with Serial Port Sharing 


A common use for Serial Port Sharing is as a mechanism to allow the serial connection to be shared between the 


BMC and with BIOS Console Redirection. Serial Port sharing includes commands to help facilitate this 


application. This section presents an overview of those commands and how they might be used. This is just a 
starting point. The actual specification of the BMC with BIOS console redirection is outside the scope of this 


specification. 
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14.2a Detecting Who Answered The Phone 


Since console redirection is normally used with a remote console, wel start from when the remote console 
first connects to the system. Depending on the configuration, either the system or the BMC may be the party 
that ‘answers the call’. Whether the BMC connects or not is determined by the access mode settings set via 
the Set Channel Access command, plus activation settings in the serial/modem configuration parameters. 
There is also a configuration parameter that allows the BMC to wait for a ‘ring interval’ before answering a 
call in order to give system software an opportunity to connect first. 


Thus, when a remote console connects to a given system, it should first try to determine whether it connected 
with the BMC or with console redirection. This avoids the possibility that the remote console will send IPMI 
message data down only to have it be mis-interpreted as console-redirection keystrokes. 


For Basic Mode and Terminal Mode, the BMC can be configured to periodically issue a Serial/Modem 
Connection Active message whenever it has the port and right after the port is switched to the BMC. The 
remote console can wait for this message as a confirmation that the BMC has the port before attempting to 
send any messages to the BMC. If that message is not received, it can assume that the system answered the 
phone instead of the BMC. 


If PPP is used, PPP communication software on the remote console will typically initiate the PPP negotiation 
without waiting for the managed system. Because of this, there is less need to send a Serial/Modem 
Connection Active message first, since by the time the message is generated the remote console has already 
sent in characters. Similarly, because there are separate port addresses that would be used for RMCP traffic to 
the BMC, there’s no strong need for the Serial/Modem Connection Active message to be periodically sent. 
Thus, the BMC does not send Serial/Modem Connection Active messages in PPP Mode except when the 
serial connection is being switched to or from the BMC. 


When the serial connection is switched over to the BMC, the Serial/Modem Connection Active message will 
be delivered to the Primary RMCP port address and IP address of the remote peer that was negotiated during 
IPCP. If the BMC did not negotiate IPCP, the Serial/Modem Connection Active message will not be sent. 


When the serial connection is being switched over to the system, the Serial/Modem Connection Active 
message will be delivered to the Primary RMCP port address and IP address of the remote peer that was 
negotiated with IPCP, and to each active session on that PPP channel. If the BMC did not negotiate IPCP, 
then the Serial/Modem Connection Active message will only be sent to the active sessions. 


If remote console software wishes to detect the presence of a BMC, it can do so by sending a Get Channel 
Authentication Capabilities message after IPCP has been negotiated. [Note that if console redirection uses 
‘ASCII’ then the remote console may have to assume that console redirection is occurring if it cannot 
establish a PPP Link. (Generally, ASCII text console redirection and PPP communication with the BMC 
don’t share well together)] 


If the system includes PPP Link authentication, the remote console could distinguish between whether the 
system or the BMC established the link based on the peer name that is used in the link negotiation. 


14.2b Connecting to the BMC 


The remote console can cause the connection to be switched back to the BMC by the mechanisms listed in 
Table 14-, Serial Port Switching Triggers. Whether switching is allowed is based on what the Access Mode 
setting is for the channel. For example, if the channel is set to ‘pre-boot only’ - then the remote console will 
not be able to remotely switch the mux over to the BMC if the system is presently in run-time operation. 


14.2c Connecting to the Console Redirection 


The Set Serial/Modem Mux command provides the mechanism for a remote console to direct the BMC to 
switch the serial connection over to the system serial controller. The <ESC>Q sequence can also be enabled 
for this purpose. 
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14.2d Directing the Connection After Power Up / Reset 


The remote console can send commands to the BMC to initiate a system power up or reset operation. After 
that operation, the remote console may want to see console redirection, or it may want to stay connected to 
the BMC. The Set Serial/Modem Mux command can be used to direct whether the remote console stays 
connected to the BMC or not. The Set Serial/Modem Mux command includes an option to allow a mux switch 
to be requested or to be forced. A mux switch that is requested may be denied (blocked). A BIOS using 
console redirection would typically request that the mux be switch over to the system during POST, so that 
the remote console could block that request if necessary. Thus, if the remote console wants to keep the 
connection, it simply issues a Set Serial/Modem Mux command to block requests to switch the mux to the 
system before sending the power up or reset command. 


14.2e Interaction with Microsoft ‘Headless’ Operation 


Microsoft has specified an interface [MSVT] for text-based console redirection to support pre-boot 
operations with the operating system. This specification includes escape sequences for activating and 
deactivating the connection to a ‘service processor’, as well as an escape sequence for hard resetting the 
system. See [MSVT] for more information. 


IPMI v1.5 includes optional serial/modem configuration parameters for supporting [MSVT] in a system that 
implements serial port sharing along with [MSVT]. These parameters provide a common way for the 
[MSVT] activate/deactivate and reset sequences to be enabled or disabled in the system. Supporting these 
options in IPMI does not imply that a given implementation is conformant with the [MSVT] specification. 
Refer to [MSVT] for the full system requirements. 


Note that the present [MSVT] specification calls out for a timeout on the escape sequence filtering. If an 
<ESC> is received, subsequent characters in the sequence must be received within 20 seconds. 


14.2f Pre-boot Only Mode 


The definition of Pre-boot Only access mode is that the BMC serial connection becomes disabled when the 
system starts to boot in order to guarantee that system software has full use of the serial connection without 
concern that incoming calls would be able to connect to the BMC. In order to provide emergency 
management coverage, someone using pre-boot only mode would typically also configure the watchdog timer 
and PEF so that a system power down or reset would occur on critical system failures, thus allowing a remote 
console to connect to the BMC. 


The remote console has the ability to use the Set Serial/Modem Mux command to block mux switch requests, 
but allow mux switch ‘forces’. This is typically used with the Pre-boot Only access mode. At the start of 
POST BIOS requests the mux. If a remote console is connected, it can block that request in order to continue 
to communicate with the BMC during POST, if desired, or the remote console can let BIOS take the mux in 
order to see BIOS console redirection. 


At the conclusion of POST and start of boot, BIOS will typically force the mux away from the BMC and to 
the system. Once the mux has been forced away from the BMC in Pre-boot Only mode, the BMC is not 
allowed to take the port back until the next time the system is powered down or is reset. 


Note that Alerting is not affected by Pre-boot Only mode. Alerting, if enabled, will ‘take over the port’ and 
cause an alert to be sent even if the system was using the port at the time. BIOS can use the Get Channel 
Access command to determine that the BMC is configured to operate in Pre-boot Only mode for the serial 
connection. 


14.2g Always Available Mode 


In Always Available Mode the serial connection is considered to be dedicated to the BMC. In order to avoid 
confusion with run-time software, BIOS will typically hide or disable the serial port when the OS load 
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process starts. BIOS can know when to do this by reading the access mode setting from the BMC using the 
Get Channel Access command. 


14.2h Shared Mode 


In Shared Mode the BMC is allowed to ‘answer the phone’ but run-time software is also able to use the serial 
connection when it’s not being used by the BMC. BIOS can use the Get Channel Access command to see 
when the BMC is configured for Shared mode. In this case, it can leave the serial port enabled for run-time 
software access. The serial/modem configuration parameters include a ‘ring interval’ parameter that can be 
used to enable the BMC to only answer the phone if system software doesn’t. This is accomplished by simply 
setting a ring interval for the BMC that is longer than the time it takes system software to answer. 


14.2.7 Serial Port Sharing Access Characteristics 


The following table lists the mux control and modem-answering characteristics according to the type of Access 
Mode and state of Serial Port Sharing. Corresponding mux switching steps that would typically be used in BIOS 
for supporting console redirection also listed. 


In general, if a remote console application wishes to keep communication with the BMC after a power-up or 
reset, it should issue a Set Serial Modem/Mux command to block mux requests before issuing a Chassis Control 
command to cause the system to power-up or reset. However, it should not block mux ‘force’ operations 
because this could interfere with run-time access of the serial connection. 


Table 14-, Serial Port Sharing Access Characteristics 


Serial Port Access 
Sharing Mode Characteristics 
disabled disabled | Same behavior for both Modem and Direct Connect Mode 
e If system power is On, Mux always set to system. When power is off Mux setting is 
unspecified. 
e Set Serial/Modem Mux command is rejected. (See response data for the Set 
Serial/Modem Mux command). 
e Escape sequence / pattern triggered switching is not available. 
e Alerting Unavailable. 
e BMC Power-on Default = mux set to system when system power is On. When power is 
off, mux setting is unspecified. 
BIOS Action at POST start: none required 
BIOS Action at POST end: none required 
disabled any Same behavior for both Modem and Direct Connect Mode 
except e Mux always set to BMC. 
‘disabled’ | e Set Serial/Modem Mux command is rejected. (See response data for the Set 
Serial/Modem Mux command). 
e Escape sequence / pattern triggered switching is not available. 
e Alerting available. 
BMC Power-on Default = mux set to BMC. 
BIOS Action at POST start: none required. 
BIOS Action at POST end: Recommend hiding/disabling baseboard serial controller. 
enabled disabled | Same behavior for both Modem and Direct Connect Mode 


e Mux always set to system (except during alerting). 

e Escape sequence / pattern triggered switching is disabled. 
e Set Serial/Modem Mux command available. 

e Alerting available. 

e BMC Power-on Default = mux set to system. 

BIOS Action at POST start: none required. 


BIOS Action at POST end: none required. 
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enabled 


pre-boot 


BMC pays attention to Modem Ring Time parameter until mux is forced to system using 
Set Serial/Modem Mux command. Afterwards, BMC will not automatically take over mux 
for IPMI messaging (will not answer the phone) until next power down or system reset 
(unless commanded). 
e Escape sequence / pattern triggered switching is available. 
e Set Serial/Modem Mux command available. 
e Alerting available. BMC will terminate call and automatically take the mux in order to 
send an alert, unless an IPMI Messaging Session is already in progress on the channel 
- in which case alert will be “deferred” until channel becomes available for dial-out. 
e BMC Power-on Default = If system power is off, or if Modem Ring Time >00h and 
<3Fh the power-on default mux setting is unspecified until Rl or DCD is detected 
(see below), otherwise set to BMC. 


For Modem Mode, the BMC automatically takes over the connection upon power down, 
after system resets, and on detecting Ring based on Modem Ring Time parameter, 
except if a session is active - in which case the BMC will keep the connection (until the 
mux is forced to system using the Set Serial/Modem Mux command). 


If Modem Ring Time parameter is >00h and <3Fh, If system power is on and the 
Ring Time countdown is running, the mux will be set to system to allow the system 
to answer the modem call. BMC will take over mux if Ring Time expires while Ring 
is being detected via the RI signal. If system power is on, the mux will be returned to 
system when loss of connection (loss of DCD) is detected, or if the BMC takes the 
mux but is unable to establish a connection. 


If Ring Time = 00h, BMC will take mux during power down and after system resets 
as necessary to be able to answer the call via the modem. BMC will also take the 
mux and connect with the modem when a Ring is detected via the RI signal. Mux 
will be claimed by the BMC whenever loss of DCD connection is detected. To the 
BMC, this is essentially the same ‘phone answer’ and power down/reset behavior as 
in ‘Always Available’ mode. 


For Direct Connect Mode the BMC automatically takes the connection upon power down, 
after system resets, and whenever loss of DCD is detected (if DCD-based switching is 
enabled) except if a session is active - in which case the BMC will keep the connection 
(until the mux is forced to system using the Set Serial/Modem Mux command). 

BIOS Action at POST start: Request mux to system if BIOS console redirection enabled. 


BIOS Action at POST end: Force to system. Keep baseboard serial controller enabled. 


enabled 


always 
available 


e Escape sequence / pattern triggered switching is available. 

e Set Serial/Modem Mux command available. 

e Alerting available. BMC will terminate call and automatically take the mux in order to 
send an alert, unless an IPMI Messaging Session is already in progress on the channel 
in which case alert will be “deferred” until channel becomes available for dial-out. 

e BMC Power-on Default = Mux set to BMC. 

For Modem Mode, the BMC automatically takes over mux on power down, system resets, 
when loss of DCD is detected, and upon detecting initial activity of RI. The BMC also 
initializes the modem whenever DCD loss is detected. The BMC ignores the Modem 
Ring Time parameter. 


For Direct Connect Mode, the BMC automatically takes the mux upon power down, after 
system resets, and whenever DCD is absent (if DCD-based switching is enabled). 


BIOS Action at POST start: Request mux to system if BIOS console redirection enabled. 


BIOS Action at POST end: Force mux to BMC. Recommend BIOS hides/disables 
baseboard serial controller. 
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enabled 


shared e Escape sequence / pattern triggered switching is available. 

e Set Serial/Modem Mux command available. 

e Alerting available. BMC will terminate call and take mux in order to send an alert, 
unless an IPMI Messaging Session is already in progress on the channel - in 
which case alert will be “deferred” until channel becomes available for dial-out. 

e BMC Power-on Default = If system power is off, or if Modem Ring Time >00h and 
<3Fh the power-on default mux setting is unspecified until RI or DCD is detected 
(see below), otherwise set to BMC. 


For Modem Mode, the BMC controls mux upon power down, after system resets, and on 
detecting Ring based on Modem Ring Time parameter, except if a session is active - in 
which case the BMC will keep the connection: 


If Modem Ring Time parameter is >00h, <3Fh. H system power is on and the Ring 
Time countdown is running, the mux will be set to system to allow the system to 
answer the modem call. BMC will take over mux if Ring Time expires while Ring is 
being detected via the RI signal. If system power is on, the mux will be returned to 
system when loss of connection (loss of DCD) is detected, or if the BMC takes the 
mux but is unable to establish a connection. 


If Ring Time = 00h, BMC will take mux during power down and after system resets 
as necessary to be able to answer the call via the modem. BMC will also take the 
mux and connect with the modem when a Ring is detected via the RI signal. Mux 
will be claimed by the BMC whenever loss of DCD connection is detected. To the 
BMC, this is essentially the same ‘phone answer’ and power down/reset behavior as 
in ‘Always Available’ mode. 


For Direct Connect Mode, the BMC takes the mux upon power down and after system 
resets, except if a session is active - in which case the BMC will keep the connection. 
Once power is up, the BMC will leave the mux in the state last commanded by software 
or an escape sequence and will not automatically take the mux unless DCD loss is 
detected (if DCD-based switching is enabled), or an alert needs to be sent. 


BIOS Action at POST start: Request mux to system if BIOS console redirection enabled. 


BIOS Action at POST end: None. BIOS leaves mux setting alone. Note that the Boot 
Options contain flags that remote software can use to request BIOS to place the mux 
into a given setting at POST end. 


14.2.8 Serial Port Sharing Hardware Implementation Notes 


There are a number of characteristics that should be considered when designing hardware that aids in the 
implementation of serial/modem remote access and Serial Port Sharing 


The BMC needs the ability to monitor the DCD and RI signals from the serial connector in order to 
detect incoming modem calls. 


The physical implementation is required to ensure that the baseboard serial controller does not receive 
characters when the serial connector is switched to the BMC. The lines in to the baseboard serial 
controller should also be placed in an appropriate ‘idle’ level. 


In order to prevent signal transitions from causing interrupts to the baseboard communication routines, it 
is recommended that the remaining serial input signals to the baseboard serial controller also be switched 
and placed into an appropriate ‘idle’ level when the BMC is using the connector. 


The physical implementation is required to handle additional serial signal lines, such as RTS and DTR, 
in order to ensure that those signals remain in the active state to keep the modem connection active when 
switching between the baseboard and the BMC. If the BMC does not have control over those signal 
levels, it may be necessary to accomplish this using additional baseboard circuitry. 


The implementation is required to ensure that the serial connection does not see glitches or signal drops 
on the RTS, CTS, DSR, DTR, DCD, and RI lines due to switching between the baseboard and BMC 
serial controllers. 
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e Itis up to the implementation to determine how it handles any ‘Wake On Ring’ options for the serial 
connector. 


e The BMC may have other RS-232 lines under its control (DTR, RTS, CTS, and DSR). Hardware 
handshake via RTS and CTS is an implementation option. A BMC implementation may also optionally 
use DTR as an additional hang-up mechanism. 


e The serial/modem feature is more valuable if the BMC can be communicated with when the system is in 
a powered-down or sleep state. This may require the port transceivers to be powered via Standby Power. 


14.2.9 Connection Mode Auto-detect 
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Connection Mode Auto-detect refers the capability for the BMC to automatically detect and enter a particular 
Connection Mode (Basic mode, PPP mode, or Terminal mode) based on detecting an appropriate data pattern in 
the serial traffic from the remote console. Implementing Connection Mode Auto-detect is optional. 


The configuration of this capability is handled via the Connection Mode parameter in the serial/modem 
configuration parameters. The parameters allow this capability to be disabled, and the BMC set to use just one 
connection mode for direct IPMI messaging to the BMC. 


The following is the description and specification of the operation of Connection Mode Auto-detect. 


e The BMC will auto-detect whenever an IPMI messaging session is not active. When a session is not active, 
the BMC constantly snoops for the different data patterns that will tell the BMC what connection mode to 
use, but also will cause the serial connection to be switched over to the BMC. The pattern matching routine 
must check for all supported mode patterns in parallel. For example, suppose the BMC supports auto-detect 
for all three connection modes. Even if it detects what looks like the start of the PPP Mode pattern, the 
pattern detection routine must continue to look for Basic Mode and Terminal Mode patterns in parallel until 
the PPP mode pattern is confirmed. 


e For modem mode, the BMC detects that a connection has been established by detecting DCD or by 
receiving a ‘CONNECT?’ string from the modem, depending on the implementation. For direct connect 
mode, the BMC uses DCD if DCD is enabled, otherwise it assumes that a connection exists any time the 
mux is switched to the BMC. 


e If Basic Mode is enabled, and the mux is set to the BMC, the BMC will assume that Basic Mode is the 
desired connection type. The BMC will send out a Serial/Modem Connection Active “Ping” messages (if 
enabled) after the connection is established. A remote console that wishes to use Basic Mode should wait 
for the Ping before sending any packets to the BMC. This will avoid the possibility of the packet from 
being interpreted as keystroke input if the remote console happens to connect to text-based console 
redirection instead of the BMC. 


e = If the mux is already switched to the BMC, the BMC can detect a PPP Link Negotiation request and use 
that to set the connection mode to PPP Mode. 


e The process is more complicated if system software performed the negotiation and the BMC is ‘snooping’ 
to see if it should be activated and enter PPP mode. The BMC needs to snoop for both compressed and 
uncompressed versions of the address and protocol fields. Note that PPP already specifies that a receiver 
must accept uncompressed headers even if compressed headers were negotiated, so this support should 
already be part of the BMC’s PPP routines. The BMC also needs to snoop according to the escaping that 
the system software negotiated. This is more problematic. The BMC needs to know what the system 
negotiated for its transmit ACCM (Asynchronous Control Character Mask) in order to know what control 
characters to ignore in the data stream. The following are options for handling this situation: 


a. Pre-configure the BMC to match the escape negotiation that software will use. The serial/modem 
configuration parameters contain a ‘Snoop ACCM’ parameter that the BMC can be directed to use. 
The Snoop ACCM indicates which control characters the BMC should ignore when snooping in PPP 
mode. 
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b. Have the BMC snoop the Link Negotiation process. The BMC monitors the transmit ACCM that the 


system is using. 


The following table lists the patterns that the BMC will look for when auto-detecting the connection mode. The 


patterns will also trigger a switch of the serial connector to the BMC if Serial Port Sharing is enabled. 


Table 14-, Auto-Connection Mode Patterns 


Connection Mode | Pattern 

Basic Mode BMC looks for a complete Get Channel Authentication Capabilities 
command in basic mode format. The BMC should also respond to 
this command. Once a basic session is established the BMC will 
stay in basic mode until the session is terminated. 

PPP Mode If the mux is already connected to the BMC, the BMC will enter 


PPP mode if it detects the start of a PPP LCP packet after the 
connection is established. The BMC shall check the PPP packet 
bytes up to and including the LCP Packet Code field. An 
implementation can elect to ignore the Identifier and Data field 
values, but the Length and FCS (Frame check sequence) must be 
correct. 


If the mux is connected to the system, the BMC will switch and 
attempt to use PPP mode if it detects a PPP packet with the 
following characteristics: 


Protocol = IPCP 

Packet = IPv4 UDP Datagram 

IP Address = BMC IP Address 

Port = Primary or Secondary RMCP port, as set in 


the serial/modem configuration parameters 
Initial packet data = RMCP v1.0 header with message class 
field = IPMI 
An implementation can elect to either switch immediately on 
detecting this pattern without additional data integrity checks, or 
wait until it has verified the checksums and FCS on the packet. 


The BMC is not required to respond to the IPMI message that was 
encapsulated in the packet. 


Terminal Mode 


Terminal Mode can be enabled to be entered on receiving an 
“<ESC>(“ sequence (if enabled). The BMC will respond with 
[TMODE OK] and will operate in terminal mode until the connection 
is terminated or the data pattern for Basic Mode or PPP Mode 
IPMI-RMCP packet is detected. 
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14.2.10 Modem-specific Options 


The serial/modem configuration parameters (set using the Set Serial/Modem Configuration command) support 
various modem configuration strings. These strings are set into non-volatile storage managed by the BMC. The 
BMC uses the strings to configure the modem for out-of-band access use. 


Due to the limited length of these strings, it may not be possible to configure all necessary modem parameters. 
Rather than relying solely on these strings, it is recommended that the user pre-configure the modem for out-of- 
band operation and save those settings in the modem as the default. The Modem Strings can then be used just to 
hold strings that trigger the modem to restore its defaults. 


The BMC automatically sends an <Enter> character (carriage return = ODh) after sending the Modem 
Initialization and Hang Up Line strings. <Enter> is not sent after the Escape Sequence string. 


Table 14-, Modem String Summary 
Minimum. 
Default String String String Usage 
Length 


Modem Init String Implementation 64 bytes, Transmitted every time the 
dependent. The string including serial/modem connection becomes 
ATE1Q0V1X4&D0S0=0 termination activated. The BMC automatically 
is a good starting point. character sends an <Enter> character after this 
string. 
Modem Hang Up 8 characters, Sent to modem whenever the BMC 
Sequence plus wants to terminate the session (i.e. 
(unused if DTR termination password retry count is exceeded, etc). 
hang-up is available character The BMC automatically sends an 
and selected) <Enter> character after this string. 
NOTE: If the DTR hang-up option is 
selected, this field will not be used. 
Modem Escape 4 characters, Informs modem that next stream of 
Sequence plus bytes should be interpreted as 
(Unused if DTR termination command bytes and not sent to the 
hang-up is character remote software. The escape sequence 
available) must be sent prior to sending any other 
command if the modem is currently 
connected with another modem. Note: 
This may cause the modem to hang up 
unless it has been configured 
otherwise. 


Escape sequence is preceded by a 2 
second pause in transmission from the 
BMC, and is follow by a 2 second pause 
in transmission. 

This sequence precedes the Modem 
Initialization string, except after a RI or 
connection after DCD loss. 


14.2.11 Modem Activation 

The BMC will monitor RI and claim the serial connection (switch the mux to the BMC) according to the Modem 
Ring Time parameter in the serial/modem configuration parameters” and Section 14.2.7, Serial Port Sharing Access 
Characteristics. After getting the connection, if DCD is already asserted, the BMC will monitor the incoming data 


2 A ring duration is used instead of a ring count in order to simplify handling the variations in RI that occur between different national 
telephone systems and modems. 
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stream for the start of an IPMI session. If DCD is not already asserted, the implementation can use one of the 
following mechanisms: 


1. The BMC will initialize the modem with the initialization string from the serial/modem configuration 
parameters. The initialization string must be configured to set the modem to answer the phone. The BMC 
then waits for DCD to become active. 


2. The BMC initializes the modem by sending the initialization string. The BMC then listens for a “RING” 
result code from the modem and sends out an “ATA” to answer the phone. 


Of these two methods, method #2 is the preferred implementation since it does require leaving the modem in an 
auto-answer state. 


14.3 Serial/Modem Connection Active (Ping) Message 


If terminal-based console redirection is used, it is important for a remote console application to know whether the 
system or the BMC is connected to the serial connector before it sends any messages. Otherwise, if the serial port 
was already connected to the system, an incoming IPMI message could be interpreted by the system as redirected 
key strokes. 


Therefore, there is a configuration option for Basic Mode and Terminal Mode that can direct the BMC to send out 
a Serial/Modem Connection Active request message once every two seconds whenever the serial connection is 
switched to the BMC, with the first message starting immediately after the connection has been switched. 


This message is also referred to as the “Serial/Modem Ping”. The message is used both to get the attention of the 
remote software and to allow the remote software to determine whether it is connected to the BMC or not. The 
Serial/Modem Connection Active message is primarily required when system console redirection is using a 
terminal-based format for input from the remote console, where incoming IPMI message characters could be 
misinterpreted as redirected input. For example, if console redirection was operating using a *'VT 100” terminal 
emulation, the characters in an incoming IPMI message might be interpreted as a command or terminal control 
escape sequence. 


If PPP is used, PPP communication software on the remote console will typically initiate the PPP negotiation 
without waiting for the managed system. Because of this, there is less need to send a Serial/Modem Connection 
Active message first, since by the time the message is generated the remote console has already sent in characters 
in an attempt to do link negotiation for PPP. Similarly, because there are separate port addresses that would be 
used for RMCP traffic to the BMC in PPP mode, there’s no strong need for the Serial/Modem Connection Active 
message to be periodically sent. Thus, the BMC does not send Serial/Modem Connection Active messages in PPP 
Mode except when the serial connection is being switched to or from the BMC. 


When the serial connection is switched over to the BMC, the Serial/Modem Connection Active message will be 
delivered to the Primary RMCP port address and IP address of the remote peer that was negotiated during IPCP. If 
the BMC did not establish the PPP Link, the Serial/Modem Connection Active message will not be sent. 


When the serial connection is being switched over to the system, the Serial/Modem Connection Active message 
will be delivered to the Primary RMCP port address and IP address of the remote peer that was negotiated with 
IPCP, and to each active session on that PPP channel. If the BMC did not establish the PPP Link, then the 
Serial/Modem Connection Active message will only be sent to the active sessions. 


Note: If the BMC configured for any mode other than Direct Connect Mode, the Serial/Modem 
Connection Active message will not be sent out unless DCD is asserted. Sending Serial/Modem 
Connection Active messages while the modem is on-hook has been shown to prevent some modems 
from answering. This also implies that the modem should not be configured to hold DCD asserted. 
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14.3.1 Serial/Modem Connection Active Message Parameters 


The Serial/Modem Connection Active message includes a parameter that indicates that a mux switch from BMC to 
the system serial controller is about to occur. This is provided to give a remote application some notification that 
the system is switching the port back over to the baseboard serial port. The Serial/Modem Connection Active 
Message with the ‘switching to system’ parameter will be sent out before the mux is switched and before the 
response is returned for the Set Serial/Modem Mux command. 


14.3.2 Mux Switch Coordination 


It is possible that the remote application committed an IPMI message for delivery to the BMC at the time that the 
switchover to the system occurred. If the mux switch occurred immediately, this means that the message might be 
delivered to the system instead of the BMC. To protect against this occurrence, the BMC can be configured to 
look for the remote console to acknowledge the Serial/Modem Connection Active message before the mux switch 
occurs. 


There is a configuration option that directs the BMC to retry sending the Serial/Modem Connection Active 
message up to three times with 20 ms between retries if it does not get an acknowledge from the remote 
console. The BMC will then switch the mux if it has not received an acknowledge-message from the remote 
console within three seconds of sending the last retry. 


The remote console acknowledges the switch by sending a Serial/Modem Connection Active request message of 
its own back to the BMC. The reason for this approach is so the BMC will return a response to the message, 
allowing the remote console to receive positive confirmation of the acknowledge message or to retry the message 
if the response is not received. 


Note that the remote console should not send messages if it has not received a Serial/Modem Connection Active 
message or other message from the BMC in the last two seconds. The three second delay provides margin to help 
ensure that the console will not transmit with a Serial/Modem Connection Active message right when BMC times 
out and the mux switch occurs. 


14.3.3 Receive During Ping 


The serial/modem interface operates in a ‘full duplex’ mode. Thus, the BMC must continue to receive message 
characters while it is transmitting a Serial/Modem Connection Active 'Ping' message, or any other IPMI 
message. 


For Basic Mode operation, the BMC must continue to handshake each message that it receives. This means that 
the BMC may insert an 'ACK' character in the middle of a Ping message transmission. 


14.3.4 Application Handling of the Serial/Modem Connection Active Message 


A robust Remote Console Application should be prepared to handle serial/modem remote access connection 
becoming deactivated or activated at any time. 


A cessation of Serial/Modem Connection Active messages indicates that the serial/modem remote access 
connection is no longer active, while the occurrence of Serial/Modem Connection Active messages indicates 
that the connection is active. Thus, if a Remote Console Application should always monitor the 
presence/absence of Serial/Modem Connection Active messages, whether the serial/modem connection is active 
or not. 


If the application is connected to the BMC, and does not receive an Serial/Modem Connection Active message 
within 2 seconds of its last transaction with the BMC should assume that the serial/modem connection has 
become deactivated. 
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Conversely, if the application is communicating with the system (e.g. console redirection) and an Serial/Modem 
Connection Active message is received, the application should recognize that the serial/modem connection has 
become reactivated. 


144 Basic Mode 


Basic Mode eliminates much of the overhead associated with PPP/UDP mode. Instead of encapsulating IPMI 
messages within an RMCP message in a UDP datagram in a PPP frame, the IPMI messages are simply encoded 
and framed for serial transmission. The price of this efficiency is that the remote console application cannot take 
advantage of built-in support for PPP and UDP in the operating system, but will need to implement IPMI 
communications routines on top of the OS’s generic support for asynchronous serial communications. 


Since Session IDs are not part of the basic IPMI message, only a single IPMI session is supported in Basic Mode. 
The BMC can use whatever Session ID value it wants for the Get Session Challenge and Activate Session 
commands. 


14.4.1 Basic Mode Packet Framing 


Framing is done with special characters to delimit the start and end of a Basic Mode packet, and to indicate the 
sequence for an escaped data byte (see following section). Framing and data byte escaping are applied after the 
message fields have been formatted. These special characters are specified in the following table. 


Table 14-, Basic Mode Special Characters 


Start Character 


Stop Character 
Packet Handshake Character 
Data Escape Character 


Basic Mode messages can be thought of as IPMB messages with the DC start and stop condition framing 
replaced with start and stop characters, and with the addition of data byte escaping to ensure that the framing 
characters are not encountered within the body of the packet. The Packet Handshake character is a special value 
that is used for implementing a level of software flow control with the remote application accessing the BMC. 
See Section 14.4.5, Packet Handshake. 


14.4.2 Data Byte Escaping 


The Start, Stop, and Escape characters are disallowed within the body of the message. This is done to ensure 
that the start and end of a message is unambiguously delimited. If a byte matching one of the special characters 
is encountered in the data to be transmitted, it is encoded into a corresponding two-character sequence for 
transmission. This encoding is summarized in the following table. 


Table 14-, BASIC MODE Data Byte Escape Encoding 


Encoded Sequence 
AAN (ESC), BON 
AAR (ESC), BEP 


AAR (ESC), BAR 
AAR (ESC), Ben 
1Bh <ESC> AAh (ESC), 3Bh 


The first character of the sequence is always the Escape character. Only the special Basic Mode characters plus 
the ASCII Escape <ESC> character, 1Bh, are escaped. (The ASCII Escape <ESC> character, 1Bh, is escaped to 
enable the BMC to snoop for certain escape sequences in the data stream, such as the <ESC>( and <ESC>Q 
patterns.) All other byte values in the message are transmitted without escaping. 
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When the packet is received, the process is reversed. If the two-byte ‘escaped’ sequence is detected in the 
packet, it is converted to the corresponding data byte value. The BMC shall reject any messages that have 
illegal character combinations or exceed message buffer length limits. The BMC may not send an error 
response for these conditions. 


14.4.3 Message Fields 


The message fields follow those used for the IPMB, as specified in the Intelligent Platform Management Bus 
Communications Protocol v1.0 Specification, with the exception of the Requester’s (rq) Slave Address and 
Responder’s (rs) Slave Address fields, which have slightly different definitions. Note, framing and data byte 
escaping are applied after the message fields have been formatted. The general message format is illustrated in 
the following figure: 


Figure 14-, Basic Mode Message Fields 


Request 
rsAddr net Fn checksum 
(SA or SWID) (even) / rsLUN 
rqAddr rqSeq / rqLUN cmd data bytes checksum 
(SA or SWID) (0 or more) 
Response 
rqAddr net Fn checksum 
(SA or SWID) (odd) /rqLUN 
rsAddr rqSeq / rsLUN cmd completion response data checksum 
(SA or SWID) code bytes (0 or more) 
Where: 
checksum 2's complement checksum of preceding bytes in the connection header or between the 
previous checksum. 8-bit checksum algorithm: Initialize checksum to 0. For each byte, 
checksum = (checksum + byte) modulo 256. Then checksum = - checksum. When the 
checksum and the bytes are added together, modulo 256, the result should be 0. 
cmd Command Byte 
completion code Completion code returned in the response to indicated success/failure status of the request. 
data As required by the particular request or response for the command 
LUN The lower 2-bits of the netFn byte identify the logical unit number, which provides further 
sub-addressing within the target node. 
netFn Network Function code 
rq Abbreviation for ‘Requester’. 
rqLUN Requester’s LUN. 
rqAddr Requester's Address. 1 byte. LS bit is 0 for Slave Addresses and I for Software IDs. Upper 
7-bits hold Slave Address or Software ID, respectively. This byte is 20h when the BMC is 
the requester. 
rqSeq Sequence number, generated by the requester. 
rs Abbreviation for ‘Responder’. 
rsLUN Responder’s LUN 
rsAddr Responder's Slave Address. 1 byte. LS bit is 0 for Slave Addresses and 1 for Software IDs. 
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Seq Sequence number. This field is used to verify that a response is for a particular instance of 
a request. Refer to [IPMB] for additional information on use of the Seq field. 


14.4.4 Message Retries 


Basic Mode Messaging utilizes the same retry mechanisms used for the IPMB, as specification in the Intelligent 
Platform Management Bus Communications Protocol v1.0 Specification. The remote application timeout should 
be based on the IPMB timeout specifications, with additional time added for delay due to the phone system. A 
remote application can determine this additional delay for a given connection based on the time it takes to 
receive the Handshake character. 


14.4.5 Packet Handshake 


The handshake character is used to signal that the BMC has freed space in its input buffers for a new, incoming 
IPMI Message. The BMC typically returns a Handshake character within one millisecond of being able to 
accept a new message, unless the controller has already initiated a message transmission, or an operation such 
as firmware update has been initiated. 


An implementation can either send the handshake character in the middle of the transmission or elect to wait to 
transmit the handshake character until the transmission in-progress has completed. If the implementation waits 
for the transmission to complete, the handshake character will typically be sent within one millisecond after the 
message transmission completed. 


If the implementation elects to send the Handshake character in the middle of an outgoing message 
transmission, if must not insert the Handshake character immediately following a Data Escape character. The 
reason for this is to allow the remote console application some flexibility in whether it processes the Handshake 
character before or after removing data escaping. 
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14.5 PPP/UDP Mode 


This mode of operation uses PPP [RFC1661] (point-to-point protocol) messaging for transmitting IP packets on 
an asynchronous link per [RFC1662] The following sections provide overview material on PPP operation in and 
explicit requirements for an IPMI implementation. The overview material is to provide context and a starting 
point for understanding the implementation. 


The material does not supercede the PPP specifications. Designers are required to refer to the PPP RFC 
reference documents for information on implementing PPP, especially regarding the states involved in opening 
and terminating a PPP link. 


All values are delivered most-significant byte first unless otherwise specified. 


PPP/UDP mode transfers IPMI Messages encapsulated in RMCP Packets. This enables RMCP ASF Messages 
as well as IPMI Messages to be delivered to the BMC. The RMCP Packets are carried within UDP datagrams 
using the same format as the IPMI LAN messages. The resultant UDP datagrams are transferred within PPP 
frames. Specifications on this message formatting are provided in the follow sections. 


14.5.1 PPP/UDP Mode Sessions 


The BMC is only required to support one session on the PPP/UDP interface. A BMC implementation may elect 
to support multiple sessions. 


14.5.2 PPP Frame Format 


PPP/UDP mode framing follows [RFC1662]. [RFC1662] specifies an ‘HDLC-like’ format for PPP frames using 
on an asynchronous serial communication media. The following figure presents an overview of this format. 


Figure 14-, PPP Frame Format 


Flag Address Control Protocol Information Padding FCS Flag Inter-frame Fill or next Address 
(7Eh) (FFh) (03h) 1or2 2or4bytes | (7Eh) 
bytes 


14.5.3 PPP Frame Implementation Requirements 


Since the flag (7Eh) indicates both the start and end of a packet, it’s possible that another flag could 
immediately follow a flag. However, the protocol also allows the ‘end’ flag to serve as both the end of one 
packet and the beginning of the next. The BMC must be able to handle both occurrences. 


In order to reduce differences between implementations, it is recommended that the BMC must explicitly 
transmit a flag on both ends of the packet?. 


Support for the 16-bit (2-byte) FCS (frame check sequence) is mandatory. 


3 Per [RFC1662], only one Flag is required between frames, but if a two flag sequence is received, it is viewed as if an empty frame 
were received between two frames where the empty frame is silently discarded. Since the flag character delimits both the start 
and end of the frame, this requirement eliminates the need for the BMC to track that it had already sent a flag on the end of the 
previous frame and thus can skip sending a flag to start the current frame. 
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14.5.4 Link Control Protocol (LCP) packets 


The following table presents a summary of the LCP Fields used in PPP. This is provided for reference only. 


Table 14-, LCP Code Fields 
Code | LCP Packet Type 
Configure-Request 
Configure-Ack 
Configure-Nak 
Configure-Reject 
Terminate-Request 
Terminate-Ack 
Code-Reject 
Protocol-Reject 
Echo-Request 
Echo-Reply 
Discard-Request 


— 
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14.5.5 Configuration Requests 


The first step in opening a PPP link is to establish the connection through the exchange of Configure packets. 
The PPP Configure-Request message is used to request changes to the link defaults. A Configure-Request is 
responded to with a Configure-Ack, Configure-Nak, or Configure-Reject packet. A link is considered 
established once the negotiation of link options has completed. If a Configure packet is received later, the link 
will be returned to the link establishment phase. 


Table 14-, Overview of PPP Configure-Ack, -Nak, & -Reject Packet Use 


LCP Packet 


Configure-Ack All options are recognized and accepted. The Options field is a copy of the Options field from the 
corresponding Configure-Request. Receipt of a Configure-Ack from both ends of the link signals that the link is 
opened and other (non-LCP) protocols may be accepted. 


Configure-Nak All options are recognized, but one or more are not acceptable. The Options field returns a list of the 
unacceptable options in the same order that the options were given in the Configure-Request. An 
implementation may append other options to prompt the peer to include those options in its next Configure- 
Request packet. 


Configure-Reject Some of the configuration options are not recognizable, or are not acceptable for negotiation. 


The format of the Configure-Request, -Ack, -Nak, and -Reject packets follow the same format, as illustrated in 
Figure 13-4, Configure-Request, -Ack, -Nak, -Reject Packet Format. 


Figure 14-, Configure-Request, -Ack, -Nak, -Reject Packet Format 
Code Identifier Length 


(Seq) 
Type1 Leni Data 


Type2 Len2 Data2 
eee 


TypeN LenN DataN 


Options 


The Code field identifies whether the Link Control Packet is a Configure-Request, -Ack, -Nak, or -Reject 
packet, per Table 14-, LCP Code Fields. 


The Identifier field is similar to the IPMI ‘Seq’ field. The value must be changed for new requests, and the 
value in the request must be returned in the corresponding Configure-Ack, Configure-Nak, or Configure-Reject 
response. 
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The Options field holds a list of 0 or more link configuration parameters to be changed, and the corresponding 
values for those parameters. The Options field should only be filled with requests for non-default values. 
Options are not required to be in any given order in a Configure-Request. But the Configure-Ack, -Nak, and - 
Reject packets do need to return the options in the same order they were given in the corresponding Configure 


Request. 


All Configuration Options that a sender wishes to negotiate are negotiated simultaneously. 


Table 14-, PPP Link Configuration Option Support Requirements 


Compression 


ID | Type Len | Data BMC Support Requirement 
1 Maximum Receive Unit 4 bytes 1:2 - 2-byte value indicating Request: Recommended. 
request It is recommended that the BMC request that 
packets smaller than 1500 bytes be used. The 
requested value must be 2 XX bytes. IPMI only 
requires XX bytes, but OEM value-added 
features may require a larger maximum packet 
size. 
Response: Optional. 
The BMC can respond to a request that larger 
or smaller packets be used. If implemented, the 
BMC must reject/nak any request to use a value 
smaller than XX bytes. The implementation can 
elect to accept >1500 bytes, at the discretion of 
the implementer. 
Note that per PPP an implementation must 
accept at least 1500 bytes. See Section 14.5.6, 
Maximum Receive Unit Handling for more 
information. 
2 Asynch Control Request and Response: Optional 
Character Map 
3 | Authentication Protocol >4 bytes 1:2 - protocol ID Request and Response: based on firmware 
C023 = PAP support for PAP, CHAP, and MS-CHAP 
C223 = CHAP [RFC1994] 
(Algorithm: 
#5 = CHAP w/MD5 [RFC1994] 
#128 = MS-CHAP v1 
#129 = MS-CHAP v2 
bytes 3:N - data according to 
protocol ID 
4 Quality Protocol >4 bytes 1:2 - protocol ID Request and Response: Optional 
C025 = Link Quality Report 
bytes 3:N - data according to 
protocol ID 
5 Magic Number 6 bytes 1:4 - magic number Request:Optional. 
Response: Recommended. 
It is recommended that the BMC indicate 
support for Magic Number. 
7 Protocol Field 2 none Request and Response: Recommended. 
Compression (PFC) It is highly recommended that the BMC support 
being configured to accept compressed protocol 
fields, and request that it can use compressed 
Protocol Fields when it transmits. 
8 | Address & Control Field 2 none Request and Response: Recommended. 


It is highly recommended that the BMC support 
being configured to receive compressed 
Address and Control Fields, and for the BMC to 
request that it can use compressed Address 
and Control Fields when it transmits. 


1. PPP requires that implementations must be able to receive a full 1500-byte information field in case link 
synchronization is lost. If an MRU value is not specified, it is assumed to be 1500 bytes. 
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14.5.6 Maximum Receive Unit Handling 


For full PPP compatibility, the BMC must accept up to 1500 bytes in the information field. The storage 
requirements could be even greater if the implementation elects to buffer the frame first and process escaped 
characters after getting the entire frame, instead of handling escaped characters as they’re received. 


Ideally, the BMC would have internal storage to hold this full amount of data, but this may not be economical in 
some implementations. If the BMC cannot directly buffer a 1500-byte MRU frame, the BMC must still continue 
to accept bytes until the end of the frame, and must not lose track of framing, terminate the link, or issue any 
error response just because of the overall frame length. 


It is possible, though unlikely, that a UDP packet could contain an RMCP message that meets the BMC buffer 
size requirements, but is padded with additional bytes that cause the PPP Frame to exceed the BMC’s buffer. 
An implementation can handle this possibility by continuing to calculate the FCS on characters received after 
the buffer has become full, before discarding those characters. Once the frame was completed, the BMC could 
check the leading contents of the buffer to see if a complete, valid message was contained in the initial bytes. 


Note that there is a UDP Checksum that would also need to be tracked. However, the BMC could opt to ignore 
the UDP Checksum field. Barring formatting errors, the data-integrity-checking role of the UDP Checksum 
should be covered by the PPP FCS. The UDP Length field should also be able to be ignored for IPMI-RMCP 
messages, since the number of bytes preceding the IPMI Message Length field is constant, and the IPMI 
Message Length will indicate the number of valid bytes remaining in the message. 


It is recommended that, for PPP frames containing RMCP/UDP packets, the implementation accept PPP frames 
greater than its buffer size, track and verify the Frame Check Sequence, and attempt to validate and interpret the 
leading, buffered data. 


14.5.7 Protocol Field Compression Handling 


The least significant bit of a protocol field indicates that the last byte of the protocol has been sent. Therefore, if 
the Is-bit of the first protocol byte position is a ‘1’, the implementation can simply assume that the protocol field 
has been compressed to one byte. 


Accepting a configuration request for Protocol Field Compression indicates that the implementation supports 
receiving compressed protocol field values. This does not obligate the transmitter to send them. Thus, the 
receiver must be able to receive frames that use both compressed and non-compressed formats. 


It is recommended that the BMC request that it can use Protocol Field Compression for the frames it sends. If 
this configuration option is accepted, the BMC itself should use it. Note there may be some cases where the 
BMC may need to transmit without using compressed fields, even though it has negotiated for compressed 
fields to be accepted. This is allowable in PPP and is also allowable in a BMC implementation. 


14.5.8 Address & Control Field Compression Handling 


Per the PPP specification, when Address & Control Field compression is used the Address and Control fields 
are simply omitted. On reception, the Address and Control fields are decompressed by examining the first two 
bytes. If they contain the values Oxff and 0x03, they are assumed to be the Address and Control fields. If not, it 
is assumed that the fields were compressed and were not transmitted. 


This works because the first byte of a two byte Protocol field will never be Oxff (since it is not even), and the 
Protocol field value OxOOff is not allowed (reserved) to avoid ambiguity when Protocol-Field-Compression is 
enabled and the first Information field byte is 0x03. 


LCP Packets are not allowed to be sent with compressed Address and Control fields. 


Accepting a configuration request for Address and Control Field Compression indicates that the implementation 
accepts frames using Address and Control Field Compression. This does not obligate the transmitter to send 
them. Thus, the receiver must be able to receive frames the use both compressed and non-compressed formats. 
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It is recommended that the BMC request that it can use Address and Control Field Compression for the frames 
it sends. If this configuration option is accepted, the BMC itself should use it. Note there may be some cases 
where the BMC may need to transmit without using compressed fields, even though it has negotiated for 
compressed fields to be accepted. This is allowable in PPP and is also allowable in a BMC implementation. 


14.5.9 IPMI/RMCP Message Format in PPP Frame 


IPMI Messages are carried in RMCP Packets in UDP using the same format as the IPMI LAN messages. This 
enables RMCP ASF Messages as well as IPMI Messages to be delivered to the BMC. RMCP support adds only 
four bytes overhead to an IPMI Session message in UDP. 


Figure 14-, IPMI Message in PPP Frame Format 


PPP Frame 


IP Header 


UDP Header 


RMCP Header 


IPMI Session 


IPMI Message 


PPP Frame 
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Field 


Flag 


Address 
Control 
Protocol 
Version and Header Length 
Service Type 
Total Length 
Identification 
Flags & Fragment Offset 
Time to Live 
Protocol 
Header Checksum 
Source IP Address 
Destination IP Address 
Source Port 
Destination Port 
UDP Length 
UDP Checksum 


FCS 
Flag 


Version 
Reserved 
RMCP Sequence Number 
Class of Message 
Authentication Type 
Session Sequence # 
Session ID 
Message Authentication Code 
(AuthCode) Not present when 
Authentication Type = none. 
IPMI Message Length 
Per Section 13.8, IPMI LAN 
Message Format 


Be en OOO 
EET or0 


aak 


11h 


26Fh 
FFh for IPMI®! 
07h for IPMI 


varies 


1 2 


Dependent on whether Address & Control Field Compression is used 
Dependent on whether Protocol Field Compression is used 
RMCP Messages with class=IPMI should be sent with an RMCP Sequence Number of FFh to indicate that an 


RMCP ACK message should not be generated by the message receiver. 


Per [RFC1662] "Each frame begins and ends with a Flag sequence... 


Only one Flag Sequence is required 


between two frames. Two consecutive Flag sequences constitute an empty frame, which is silently discarded 
an not counted as an FCS error.” The implementation should take care to track that a single flag character may 
indicate both the end of the present packet, and the start of the next. 


The Session ID and Session Sequence Number must be non-zero for commands executed during an active 


session. All 0’s for the Session ID and/or Session Sequence Number (null Session ID, null Session Sequence 
Number) are special values only used for commands that can be executed prior to establishing a session, e.g. 
Get System GUID, Get Channel Authentication Capabilities, and Get Session Challenge. The Activate Session 
command uses a null Session Sequence Number before a session is activated, but does not use a null Session 
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ID. Instead, it must use the Temporary Session ID given by the BMC in the response to the Get Session 
Challenge command. 


14.5.10 Example of IPMI Frame with Field Compression 


A PPP frame for IPMI in UDP/RMCP that uses both Protocol and Address-and-Control Field compression will 
have the following format. Note that per PPP, uncompressed frames must also be accepted at any time. Buffer 
sizes must take this into account. 


Figure 14-, IP Frame with Field Compression 
Flag Protocol UDP/RMCP/IPMI Packet data FCS Flag 
(7Eh) | (21h = IPv4) 2 bytes | GEN 


14.5.11 Frame Data Encoding 


In order for the Flag and Control-Escape bytes to be utilized, they must not appear directly in the data stream. 
The encoding of utilizes an escaping mechanism where bytes in packet are replaced with a two-character 
sequence in order to prevent them from being mis-interpreted as being flag or Control-Escape bytes. The 
escaping mechanism can also be used to prevent bytes from being interpreted as ASCII control characters. 


Only bytes between flag bytes are escaped. The flag byte themselves are never escaped. 


14.5.12 Escaping Algorithm 


To ‘escape’ a character, N, the BMC simply emits a 7Dh character, followed by N exclusive-OR’d with 20h. To 
convert the escaped-pair back to the original data byte, the 7Dh is thrown away and the second character 
exclusive-OR’d with 20h. 


14.5.13 Escaped Character Handling 
By default, the following characters are escaped: 


Table 14-, Default Escaped Characters 


Character value Escaped as: 
Control Escape 7Dh 7Dh, 7Dh 
Flag 7Eh 7Dh, 5Eh 
ASCII Control Characters 00h-20h 7Dh, (value XOR 20h) 


The BMC must ignore non-escaped versions of the above characters as part of the frame data, unless there has 
been a negotiation that allows some of the characters to be sent without escaping. (See Section 14.5.14, Asynch 
Control Character Maps (ACCM), below) The control-escape character and flag characters still need to be 
interpreted, of course. 


The reason that non-escaped characters are dropped is that an intervening communication device may have 
inserted the characters. 


Only non-escaped characters are eligible to be dropped on receipt as spurious characters in the frame data. The 
BMC must accept all escaped characters received within flag delimiters as part of the frame data. 


14.5.14 Asynch Control Character Maps (ACCM) 


PPP includes an option that allows the negotiation of which characters require escaping and which can be 
optionally escaped. This is accomplished by negotiating ACCMs (Asynch Control Character Maps) between 
both ends of the link. ACCM negotiation can potentially improve data throughput by reducing the number of 
characters that require escaping. 
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The BMC is not required to support ACCM negotiation. If ACCM negotiation is not supported, the BMC must 
handle character escaping and escaped characters as described in Section 14.5.13, Escaped Character Handling. 


ACCMS are negotiated using a 32-bit parameter where each bit corresponds to a character from 00h to 1Fh, 
with the least-significant bit corresponding to OOh. When sent in a configure-request, the ACCM indicates 
which values that the originator of the request must receive in escaped format, and which can optionally be sent 
without escaping. This ACCM is referred to as the ‘receiving ACCM’. 


The ‘sending ACCM’ is the set of characters that will be sent with escaping, barring any additional 
configuration due to a configure-request. By default, the sending ACCM is FFFFFFFFh - indicating the set of 
default escaped characters listed in Table 14-, Default Escaped Characters. The sending ACCM can only 
change as the result of receiving a configure-request indicating that fewer characters need to be escaped. Note 
that a transmitter can send escaped codes for values >1Fh (in addition to the required escaping of the flag and 
control-escape values). These cannot be configured via negotiation, however. 


The receiver of the configuration-request can respond with a configure-ack for the option, or it can responds 
with a configure-nak and return the union of the requested ACCM with the ACCM that it will be using for 
transmission. For example, suppose the remote console was hard-coded to always escape character ODh for 
some reason. If the BMC submitted an ACCM indicating that it required only characters 03h and 04h to be 
escaped, the remote console could respond with a configure-nak that it would always escape 03h, 04h, and ODh. 
This would tell the BMC that it should also ignore ODh characters in the data. 


The receiving ACCM is assumed to be FFFFFFFFh by default. That is, a transmitter must escape values OOh- 
1Fh (plus flag and control-escape values encountered in the frame data) unless it receives a configure-request 
indicating that certain values do not need to be escaped. This also means that the receiver can expect to receive 
OOh-1Fh in escaped format until it has successfully configured an alternative. 


14.5.15 IP Network Protocol Negotiation (IPCP) 


Once the PPP link has been established, it is necessary to send NCP (network control packets) to choose and 
configure one or more network layer protocols. 


[RFC 1332] describes IP Control Protocol (IPCP). IPCP is a network control protocol used to choose transfer of 
IPv4 packets via PPP. The BMC must both accept IPCP configuration requests and generate IPCP configuration 
requests. 


e BMC shall Configure-Ack an IPCP Configure-Request that contains 0 (zero) configuration options. 


e BMC shall issue a Configure-Request for IPCP option 3 (IP Address) to request that the IP Address 
specified by the PPP IP Address parameter (see Table 25-, Serial/Modem Configuration Parameters) be 
used as the BMC’s IP Address. 


—  IfIP Address Assignment is enabled in the serial/modem configuration parameters, the BMC shall 
accept an address assignment that is returned via a corresponding Configure-Nak from the remote 
console. 


—  IfIP Address Assignment is not enabled (Fixed IP Address), the BMC shall not accept a different 
address assignment returned via a corresponding Configure-Nak from the remote console. If the BMC 
PPP IP Address is not accepted, the BMC shall issue a new Configure-Request with the same PPP IP 
Address value (but a new identifier value). This will be repeated until the PPP IP Address parameter is 
accepted, or at least three Configure-Requests for setting the PPP IP Address parameter have been 
issued. 


e The BMC shall silently discard later IP Protocol (0021h) UDP packets that are addressed to the Primary or 
Secondary RMCP ports, but do not match the negotiated PPP IP Address. 


e BMC shall accept IPCP option 3 (IP Address) in an IPCP Configure-Request, unless that message matches 
the BMC’s PPP IP Address. 
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e BMC shall Configure-Nak IPCP option 3 if IP Address Assignment is disabled, and return the PPP IP 
Address value from the serial/modem configuration parameters in the Configure-Nak. 


e BMC shall Configure-Reject IPCP option 1, IP Addresses. This option has been deprecated in IPCP. 
e BMC shall Terminate-ACK a Terminate-Request for IPCP. 


e The BMC shall not transmit IPv4 protocol (002 1h) packets after an IPCP Terminate-Request has been 
received, until IPCP is renegotiated. 


e The BMC shall silently discard any IPv4 protocol packets received after an IPCP Terminate-Request has 
been received, until IPCP is renegotiated (the BMC receives its first IPCP Configure-Request). 


e BMC may accept other IPCP options to support OEM features. For example, Option 2 is Van Jacobsen 
compression for TCP/IP. Remote stacks must be prepared for the potential that a BMC implementation 
might request network protocols and/or configuration options beyond those specified in this document. 


e BMC shall not enable OEM framing extensions alongside PPP mode. It is possible that an OEM may want 
to include proprietary serial framing formats or special handshake or escape sequences that are not 
specified in this document, but that work as a proprietary extension to PPP mode. The BMC will not be 
considered to be conformant for PPP mode if these extensions are active. It is acceptable for the BMC to 
have an OEM-specific option to enable/disable OEM extensions. In this case, conformance will only be 
assessed when such OEM extensions are disabled. Remote stacks and remote console applications designed 
for IPMI may break when OEM extensions are enabled. 


e The BMC shall Request the remote console IP Address by issuing a configure-request for Option 3 with an 
IP Address value of 00.00.00.00 [This provides a mechanism for the BMC to obtain the remote console 
connection’s IP Address in order to enable the BMC to asynchronously send UDP datagrams to the remote 
console. ] 


e The BMC shall accept IPv4 Protocol Packets (002 1h) once it has received and responded to an IPCP 
Configure-Request from the remote console. 


14.5.16 CHAP Operation in PPP Mode 


An implementation can support CHAP as a mechanism for authenticating the serial/modem connection at the 
link level. This option is separate from the whether or not RMCP/IPMI Message packets are authenticated once 
the link has been established. Serial/modem configuration options to select and support either standard CHAP 
[RFC1994], MS-CHAP v1 [RFC2433], or MS-CHAP v2 [RFC2759] are provided. 


There are two classes of configuration options for CHAP: 


e IPMI Messaging: There is a single set of options that configures what type of CHAP, if any, is used for 
serial/modem IPMI messaging with the BMC in PPP Mode. These are referred to as PPP Link options in 
the serial/modem configuration parameters. See Table 25-, Serial/Modem Configuration Parameters. 


e Callback and Dial-out Alerting. Another class of PPP options relates to user names and accounts for 
connecting with a remote system via a PPP-to-LAN connection. The specification supports multiple sets of 
these options. The option sets are grouped under a PPP Account Selector number in the configuration 
parameters. The PPP Account Selector provides the link that associates a set of PPP account parameters 
with a particular serial/modem Alert or Callback destination. 


The Set/Get User Name, Set/Get User Access, and Set/Get Channel Access commands are used to configure the 
password and username associated with CHAP link-level authentication for IPMI messaging in PPP mode. Note 
that the same User Names and passwords that are used for link authentication can either be the same as those 
used for IPMI Messaging, or they can be different. There is a bit setting associated with the Set User Access 
command that determines whether the information associated with a given User ID is to be used for PPP Link 
Authentication (e.g. CHAP), or IPMI Messaging Authentication, or both. 
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PPP Account | is used to hold information for both IPMI Messaging via PPP and for callback, such as the IP 
Address that the BMC will attempt to negotiate for itself. 


14.6 Serial/Modem Callback 


Callback provides a serial/modem channel mechanism that enables a remote console to direct the BMC to call a 
pre-configured destination and attempt to establish an IPMI Messaging connection. Callback provides both a 
security enhancement and a way to ‘reverse’ phone charges associated with managing a system. 


Callback is primarily for use under the Modem connection mode. It can, however, be used with Direct Connect 
mode for testing and development purposes. For example, PPP destination parameters could be tested locally 
without requiring going through a modem. It’s potentially possible to locally verify parameters or do testing by 
looping back from one system serial port to another using a ‘null modem’ cable. 


Once the callback connection has been established, the BMC waits for the remote application to activate a session 
with the BMC by issuing a Get Session Challenge command, etc. 


If the Serial/Modem Connection Active (Ping) message is enabled, the BMC will announce its presence by 
periodically sending the Ping once the connection has been established. The call will be automatically terminated 
if the remote system does not activate a session with the BMC within the Session Inactivity Timeout interval for 
the channel (See Section 6.12.15, Session Inactivity Timeouts). 


IPMI Messaging and Callback use the same mode setting (basic mode, PPP mode, or terminal mode). I.e. you 
can’t request callback using one messaging mode, and have the BMC connect using a different messaging mode. 
The Callback function is implemented at the IPMI Message level. PPP Callback (I.e. PPP LCP option OD) is not 
used. For callback, the PPP Account Set settings parameters are only used if IPMI Messaging for the channel is 
set to PPP Mode. 


In order to initiate a callback, the remote console first connects to the BMC using a pre-configured User ID and 
then issues the Callback command. The User ID can be restricted to ‘Callback level’ privilege so that the only 
operation that can be performed is to initiate a callback using the Callback command. A User ID can also be 
restricted to only be accessible while a callback connection is active. Together, this provides the option to allow 
one User ID and password to initiate the callback, while making it necessary to have a callback connection active 
in order to perform any higher-privilege level connections to the BMC. 


The Set User Access command is used to configure, on a per channel basis, whether a given user is enabled, what 
the user’s limits are, and whether user access is restricted to only being available during a callback connection. 


The Callback, Operator, and Administrator privilege levels can be used to initiate a Callback, but the User Level 
cannot. This is consistent with the definition of User privilege. 


14.6.1 Callback Control Protocol (CBCP) Support 


An implementation that supports PPP can elect to support the Microsoft Callback Control Protocol (CBCP). 
CBCP is a Microsoft Corporation specification for supporting callback from a Microsoft RAS (Remote Access 
Services) PPP connection. Other devices such as serial-to-LAN gateways may also support CBCP. See [CBCP] 
for specification information. 


With respect to the BMC, CBCP provides a protocol by which a remote console can request the BMC to initiate 
a callback to the remote console. 


CBCP is negotiated during the initial LCP phase. Once CBCP has been negotiated, per [CBCP] the BMC 
initiates the callback process by issuing a request that tells the remote console what callback number options are 
available from the implementation. 


A BMC implementation can support one or any combination of the callback number options listed in the 
following table. An implementation may elect to implement CBCP callback numbers such that different users 
can have different callback numbers, or where callback numbers are shared across users. 
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Table 14-, CBCP Callback Number Options 


Option Description 

No Callback The remote console requests not to be called back at all. 

Callback to caller-specified | The BMC indicates that it allows the remote console to specify which number 
number is to be called back. 

Callback to a pre-specified | The BMC calls back a pre-configured phone number. 

number 


If a PPP Link authentication protocol such as CHAP is used, the BMC uses 
the user id string from the authentication negotiation to look up which phone 
number to use for the given user. Otherwise, a global number associated with 
the serial/modem configuration parameters for the channel will be used. 


Callback to one from a list 
of numbers 


The BMC offers up a list of possible phone numbers that the callback can be 
directed to. The remote console picks one and returns it to the BMC. If the 
number matches one from the list, the BMC calls that number. 


If a PPP Link authentication protocol such as CHAP is used, the BMC uses 
the user id string from the authentication negotiation to look up which set of 
phone numbers to offer to the given user. Otherwise, a global set of numbers 
associated with the serial/modem configuration parameters for the channel will 
be used. 


14.6a CBCP Address Type and Dial String Characters 


CBCP includes an Address Type field that indicates the format used for callback addresses. Address Type = 1 
indicates PSTN/ISDN. No other Address Type values are specified, therefore this field is, by default, a fixed 


field for IPMI implementations. 


Per [CBCP] callback strings are null terminated ASCII strings formed from the following set of characters: 


0-9, *, #, T, P, W, @, comma, space, dash, and parentheses. 


This specification applies to using NT RAS as the dialer. For IPMI 1.5, however, the BMC is the dialer. Thus, 
additional characters specified in section 14.11.1, Alert Strings for Dial Paging can also be used in the Dial 


String for CBCP callback. 


IPMI 1.5 implementations do not check for illegal characters in dial strings. It is the responsibility of 
configuration software to ensure that correct characters are entered. 


14.7 Terminal Mode 


Terminal Mode is an operating mode of a serial/modem channel used for the following purposes: 


e It provides a printable text-based mechanism for delivering IPMI between a terminal or remote console and 
the BMC. The text-based approach makes it simpler to develop script-based tools for generating and handling 


IPMI messages. 


e It provides a small number of ASCII-text based commands to enable a small number of basic recovery and 
status functions to be executed when only a dumb terminal is available in lieu of real system management 


software. 


14.7.1 Terminal Mode Versus Basic Mode Differences 


Terminal Mode is primarily intended for local use rather than remote use via a modem. The following are the 
main differences between terminal mode and basic mode operation: 
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e If password protection is desired, only ‘plain text’ passwords can be used. Password characters are 
restricted to be from the printable set of ASCII characters as defined in Appendix E - Terminal Mode 
Grammar. 


e Passwords can be entered two ways in Terminal Mode: either via the Get Session Challenge / Activate 
Session command, or via an ASCII Text command. 


e Terminal Mode does not utilize checksums on IPMI messages or ASCII Text commands. If a modem 
connection is used, the modem should be configured for error correction, or Basic Mode should be used 
instead. 


e Terminal Mode remote console is limited to a single, fixed, single Software ID (SWID). See Table 5-, 
System Software IDs. The fixed SWID is used where a requester’s SWID would have been extracted from 
the IPMI Message. For example, if Terminal Mode IPMI Messaging is used to generate a Platform Event 
Request message (Event Message) the SEL Record would contain the fixed SWID identifying the Terminal 
Mode remote console. 


e The Terminal Mode remote console is limited to a single LUN (00b). This LUN is implicit in the message 
format. When Terminal Mode request or response messages are bridged to other media, the value 00b is 
used as requester’s or responders LUN, respectively. 


e Terminal Mode messages delivered to SMS via BMC LUN 10b always go to SMS Software ID 20h (41h) 
LUN 00b, unless the Send Message command is used to put the message in the receive message queue. 


e Callback is not supported for Terminal Mode. You can trigger a callback from Terminal Mode, but the 
party that is called must support either Basic Mode or PPP Mode. 


14.7.2 Terminal Mode Message Format 


Terminal mode messages are of the general format: 
[<message data>]<newline> 


The left-bracket and right-bracket+<newline> characters serve as START and STOP delimiters for the message. 
Note that the right-bracket and <newline> characters together form the sequence that indicates the end of the 
message. <newline> characters may appear within the message as a result of input line editing and multi-line 
output message data. 


14.7.3 IPMI Message Data 


194 


IPMI Messages are sent and received in Terminal Mode <message data> as a series of case-insensitive hex- 
ASCII pairs, where each is optionally separated from the preceding pair by a single <space> character. The 
following is an example of an IPMI Request message in Terminal Mode: 


[18 00 22]<newline> 


The Terminal Mode Request Message field definitions follow those used for the Basic Mode except that there is 
no Slave address / Software ID field or LUN information for the requester. The software ID and LUN for the 
remote console are fixed and implied by the command. The SWID for messages to the remote console is always 
40h, and the LUN is OOb. 


Instead, there is a ‘bridge’ field that is used to identify whether the message should be routed to the BMC’s 
bridged message tracking functionality or not. 
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Figure 14-, Terminal Mode Request to BMC 
Byte 1 Byte 2 Byte 3 Byte 4:N 


NetFn (even) / rsLUN=00b (BMG) | rqSeq/Bridge=00b (BMC) | cmd 


The following figure shows the corresponding format of a response message from the BMC. 


Figure 14-, Terminal Mode Response from BMC 
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5:N 
NetFn (odd) / rsLUN=00b (BMC) rqSeq/Bridge=00b (BMC) Cmd Completion Code Data 
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14.7.4 Terminal Mode IPMI Message Bridging 


The terminal mode message includes a ‘bridge’ field that is used to determine whether the message is going to 
or coming from the BMC’s command functionality, or to/from the BMC’s ‘bridge’ tracking functionality. 


The message is interpreted based on the value of the bridge field, whether the message is a request or response, 
and the message direction per the following table. 


Note that messages to and from the system interface are transferred using the BMC SMS LUN, 
10b, with the bridge field set to OOb. 


Support for Terminal Mode IPMI Message Bridging is optional. 
Table 14-, Terminal Mode Message Bridge Field 


Message 
Bridge | Request/ Direction 
Field Response | (toBMC) | LUN | Message Interpretation 
00b Request In 00b, | Remote Console request to BMC functionality 
sår Message is a request from the remote console to the BMC 
00b Response Out 00b, | Response to Remote Console from BMC functionality 
AR Message is a response to an earlier request from the remote console to the BMC 
00b Request In 10b | Remote Console request to SMS 
Message is a request from the remote console to SMS via the Receive Message 
Queue 
00b Response Out 10b | SMS Response to Remote Console 
Message is a response to an earlier request from SMS 
00b Request Out 00b, | Asynchronous Request to Remote Console from BMC 
O1b, 
11b 
00b Response In 00b, | Remote Console Response to earlier Asynchronous Request from BMC 
O1b, 
11b 
00b Request Out 10b | Asynchronous Request from SMS to Remote Console 
00b Response In 10b | Remote Console Response to earlier Asynchronous Request from SMS 
01b Request In any | ILLEGAL COMBINATION 
The remote console bridges requests to other media by encapsulating the 
message content in a Send Message command to the BMC functionality. 
01b Response Out any Response to earlier Bridged Request from Remote Console 
Message is the asynchronous response from an earlier bridged request that was 
encapsulated in a Send Message command issued to the BMC by the remote 
console. 
01b Request Out any | Asynchronous, bridged request to remote console from other media 
Message is a bridged request to the remote console from another media, e.g. the 
system interface. BMC assigns the sequence number as part of bridging. 
01b Response In any Remote Console response to earlier asynchronous request from another 
media Message is a response from the remote console to an earlier bridged 
request from another media. BMC uses the sequence number in the response to 
determine how to route the response to the original requester. 


14.7.5 Sending Messages to SMS 


Terminal Mode uses BMC LUN 10b to send messages to SMS (system interface) via the Receive Message 
Queue in the BMC. The following shows the format of a request message delivered to SMS, and the 
corresponding response. 
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Figure 14-, Terminal Mode Request to SMS 
Byte 1 Byte 2 Byte 3 Byte 4:N 


NetFn (even) / rqSeq =XX / cmd 
rsLUN=10b (BMC to SMS) | Bridge=00b (BMC) 
Figure 14-, Terminal Mode Response from SMS 
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5:N 


NetFn (odd) / rqSeq =XX / cmd completion data 
rsLUN=10b (BMC to SMS) Bridge=00b (BMC) code 


14.7.6 Sending Messages to Other Media 


The Send Message command is used to deliver a message to a different media, e.g. IPMB. The following figure 
illustrates the data contents that would be used in a Send Message command to deliver a Terminal Mode request 
to another (non-system interface) channel: 


This data would be carried in a Send Message command of the following format: 


Figure 14-, Send Message Command for Bridged Request 
NetFn (even) / BMC LUN rqSeq / bridge=00b cmd = Send Message 


rsSWID 


netFn (even)/rsLUN chk1 rqSWID=81h rqSeq/rqLUN=00b 
(terminal mode console) 


The BMC will return a Send Message response matching the Send Message request. This will normally be 
returned immediately after the request.* 


Figure 14-, Response to Send Message Command for Bridged Request 
NetFn (odd) / BMC_LUN rqSeq / bridge=00b cmd = Send Message completion code 
= 00h (OK) 


Later, the bridged response will be returned. The following figure shows the contents of a corresponding 
bridged response to the Remote Console: 


Figure 14-, Bridged Response to Remote Console 
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5:N 
netFn (odd) / rsLUN rqSeq / bridge=01b Cmd Completion Code Data 


Note that much of the targets addressing information (rqSWID, rqLUN) is absent from the response. The 
remote console must use the original request’s sequence number (rqSeq), netFn/rsLUN, and command values to 
match bridged response up with the earlier bridged request. These fields are highlighted with bold in the 
preceding Send Message and Bridged Response figures. 


* Note that because IPMI messaging allows for other messages to appear between requests and responses, it is possible that one 
or more asynchronous messages could appear between the Send Message request and response. Console software should be 
prepared to handle such occurrences. 
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14.7.7 Terminal Mode Packet Handshake 


There is a configuration option that allows the BMC to output a character sequence that indicates when its input 
buffer is ready to accept another IPMI Message via Terminal Mode. This option is typically used with 
automated applications that send and receive IPMI Messages using Terminal Mode. The BMC outputs the 
following character sequence whenever there is space for a new input message from Terminal Mode, and the 
‘handshake’ option is enabled: 


[SYS]<newline> 


If a message transmission from the BMC is already in progress, the handshake sequence will be held-off until 
the present message transmission has completed. The BMC will typically output the handshake sequence within 
Ims of the buffer space becoming available and the present message transmission (if any) completing. 


14.7.8 Terminal Mode ASCII Text Commands 


A small number of ASCII-text commands can be delivered while in terminal mode. The following table lists 
these commands. Commands are CASE SENSITIVE. Appendix E - Terminal Mode Grammar, lists the rules for 
the format of terminal mode input and output for both IPMI messages and text commands. Refer to Table 
13-13, Terminal Mode Examples for some examples of Terminal Mode text command and IPMI messages. 


Table 14-, Terminal Mode Text Commands 


Command Text Description 
SYS PWD -U USERNAME | Used to activate a terminal mode session. USERNAME corresponds to the ASCII text 
<password> for the username. <password> represents a printable password (up to 16 characters). 


If <password> is not provided, then a Null password (all binary O's) is submitted. 
Passwords are case sensitive. 


Either the SYS PWD command (or Activate Session IPMI message) must be 
successfully executed before any command or IPMI messages will be accepted. Note 
that a modem connection may be automatically dropped if multiple bad passwords are 
entered. 


SYS PWD -N <password> | -N represents a Null username. <password> represents a printable password (up to 16 


characters). If <password> is not provided, then a Null password (all binary O's) is 
submitted. Passwords are case sensitive. 


Either the SYS PWD command (or Activate Session IPMI message) must be 
successfully executed before any command or IPMI messages will be accepted. Note 
that a modem connection may be automatically dropped if multiple bad passwords are 
entered. 


SYS PWD -X -X immediately ‘logs out’ any presently active session. Entering an invalid password 


with -U or -N will also have the same effect. 


SYS TMODE Used as a ‘no-op’ confirm that Terminal Mode is active. BMC returns an OK response 


followed by “TMODE”. 


SYS SET BOOT XX YY Sets the boot flags to direct a boot to the specified device following the next IPMI 
ZZ AA BB command or action initiated reset or power-on. XX...BB are five hex-ASCII bytes for the 


boot flags parameter in the Boot Options Parameters. See Table 28-, Boot Option 
Parameters. 

Upon receiving this command, the BMC will also set the ‘valid bit’ in the boot options, 
and will set all the Boot Initiator Acknowledge data bits to 1b. 


SYS SET BOOTOPT NN This is essentially a text version of the IPMI “Set System Boot Options” command, 


XX.. 


NN allows any of the boot option parameters to be set, not just the boot flags. XX...NN 
represents the hex-ascii for the data bytes that are passed in the Set System Boot 
Options request. 


SYS GET BOOTOPT XX This is essentially a text version of the IPMI “Get System Boot Options” command, 
YY ZZ allows any of the boot option parameters to be set. XX YY ZZ represents the hex-ascii 


for the data bytes that are passed in the Get System Boot Options request. The BMC 
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returns the data from the command in hex-ascii format, with a maximum of four hex- 
ascii pairs per line. 


SYS SET TCFG 


Returns the Terminal Mode Configuration bytes where XX and YY represent hex-ascii 
encodings for the volatile version of data bytes 1 and 2 as specified in the Terminal 
Mode Configuration parameter (#29) listed in Table 25-, Serial/Modem Configuration 
Parameters, and AA BB represent hex-ascii encoding of the non-volatile version. 


V:XX YY<output termination sequence> 
N:AA BB<output termination sequence> 


SYS SET TCFG -V XX YY 


This command sets the volatile Terminal Mode Configuration. XX and YY represent 
hex-ascii encodings for data bytes 1 and 2 as specified in the Terminal Mode 
Configuration parameter (#29) listed in Table 25-, Serial/Modem Configuration 
Parameters. The BMC returns the same output as for SYS SET TCFG, above. 


SYS SET TCFG -N XX YY 


This command sets the non-volatile Terminal Mode Configuration. XX and YY represent 
hex-ascii encodings for data bytes 1 and 2 as specified in the Terminal Mode 
Configuration parameter (#29) listed in Table 25-, Serial/Modem Configuration 
Parameters. The BMC returns the same output as for SYS SET TCFG, above. 


SYS RESET 


Directs the BMC to perform an immediate system hard reset. 


SYS POWER OFF 


Directs the BMC to perform an immediate system power off. 


SYS POWER ON 


Causes the BMC to initiate an immediate system power on 


SYS HEALTH QUERY 


Causes the BMC to return a high level version of the system health status in ‘terse’ 
format. The BMC returns a string with the following format if command is accepted. 
PWR:zzz H:xx T:xx V:xx PS:xx C:xx D:xx S:xx O:xx 


Where: 
PWR is system POWER state 
is overall Health 
is Temperature 
is Voltage 
S is Power Supply subsystem 
is cooling subsystem (Fans) 
is Hard Drive / RAID Subsystem 
is physical Security 
is Other (OEM) 


e le auf dn as 


zzz is: “ON”, “OFF” (soft-off or mechanical off), “SLP” (sleep - used when can't 
distinguish sleep level), “S4”, “S3”, “S2”, “S1”, “??” (unknown) 


and xx is: ok, nc, cr, nr, uf, or ?? where: 


“ok” = OK (monitored parameters within normal operating ranges) 

“nc” = non-critical (‘warning’: hardware outside normal operating range) 

“cr” = critical (‘fatal’ :hardware exceeding specified ratings) 

“nr” =non-recoverable (‘potential damage’: system hardware in jeopardy or 
damaged) 


“uf” = unspecified fault (fault detected, but severity unspecified) 
“2?” = status not available/unknown (typically because system power is OFF) 


SYS HEALTH QUERY -V 


Causes the BMC to return a high level version of the system health status in multi-line 
‘verbose’ format. The BMC returns a string of the following format: 


SYS Health:xx<output termination sequence> 

Power: “ON”, “OFF” (soft-off or mechanical off), “SLEEP” (sleep - used when can't 
distinguish sleep level), "54”, “S3”, “S2”, “S1”, “Unknown” 

Temperature :xx<output termination sequence> 

Voltage:xx<output termination sequence> 

PowerSystem:xx<output termination sequence> 

Cooling:xx<output termination sequence> 

Drives:xx<output termination sequence> 

Security:xx<output termination sequence> 
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Other:xx<output termination sequence> 


Where xx is: 
“OK” (monitored parameters within normal operating ranges) 
“Non-critical” (‘warning’: hardware outside normal operating range) 
“Critical” (‘fatal :hardware exceeding specified ratings) 
“Non-recoverable” (‘potential damage’: system hardware in jeopardy or damaged) 
“Unspecified fault” (fault detected, but severity unspecified) 
“Unknown” (status not available/unknown (typically because system 


power is OFF) 


SYS IDENTIFY 


Causes the BMC to signal the system’s location (e.g. with a blinking led or beep). This 
is intended to locate the system amongst a rack of systems. The BMC will signal the 
system’s location for 15 seconds and then stop signaling. This is a text version of the 
optional Chassis Identify command. 


SYS IDENTIFY -ON <XX> 


Causes the BMC to signal the system’s location (e.g. with a blinking led or beep) for a 
specific amount of time. XX is an optional hex-ASCII byte representing the number of 
seconds the BMC is to cause the system to identify itself. If XX is not supplied, the 
BMC will signal the system’s location for 15 seconds and then stop signaling. This is a 
text version of the optional Chassis Identify command. 


SYS IDENTIFY -OFF 


Causes the BMC to stop signaling the system’s location. This has no effect if the 
system is not currently identifying itself. This is a text version of the optional Chassis 
Identify command. 


SYS XXXXXX yy..ZZ 


OEM Text Commands (optional, vendor-specific). All OEM text commands are prefixed 
with SYS followed by XXXXXX where XXXXXX is the OEM ID expressed as a six-digit 
hex-ASCII number. For example, the IANA OEM IDs for Intel, HP, Dell, and NEC are 
000157h (343), 00000B (11), 0002A2h (674), and 000077 (119), respectively. yy..zz 
represents OEM-specific text. 

It is recommended that OEM Text Command implementations use the same OK and 
ERROR completion returns be used for OEM Commands as for the IPMI-specified text 
commands. 
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14.7.9 Terminal Mode Text Command and IPMI Message Examples 


The following table presents some examples of terminal mode commands and IPMI messages. 


Table 14-, Terminal Mode Examples 


Console input: 


BMC responds: 


[SYS TMODE}<crif> 


[OK TMODE)}<crif> 


TMODE is a ‘no-op’ command used to confirm the 
BMC is operating in terminal mode. 


Console input: 
BMC responds: 


[SYS PWD -U Fred letME1n]<crlf> 
[OK]<crlf> 


User submits password for username Fred. 


Console input: 


BMC responds: 


[SYS PWD -N]<crif> 


[ERR CC] 


User attempts to activate session with anonymous 
login (null username, null password) 


BMC returns error, e.g. ‘invalid data field’. 


Console input: 
BMC responds: 


[SYS RESET]<crIf> 
[OK]<crlf> and resets system. 


User resets system. 


Console input: 
BMC responds: 


[sys blah]<crlf> 
[ERR C1]e<crif> 


User enters an invalid command. 


Console input: 
BMC responds: 


[sys health query -Vlecrlf- 
[OK<crlf> 
Health:Critical<crif> 
Temperature:OK<crlf > 
Voltages:OK<crlf> 

Drive Subsystems:OK<crlf> 
Power System:OK<crlf> 
Cooling:Critical<crlf> 
Security:OK<crlf> 
Other:OKJ<crlf> 


Verbose system health query. 


Console input: 


BMC responds: 


[18 xx 22]<crlf> 


[1C xx 22 00]<crif> 


IPMI Reset Watchdog Timer request message to 
BMC. xx represents the console selected sequence 
number and LUN field for the request. 

Reset Watchdog Timer response message from 
BMC. The same sequence number and LUN passed 
in the request is returned in the response. 


Console input: 
BMC responds: 


[SYS 000157 My Command]<crlf> 
[OK 000157 My Response]<crif> 


Submit an OEM text command 
Get an OEM text response 


14.8 Terminal Mode Line Editing 


Since direct human input is likely to be used with Terminal Mode, it is useful to support a limited amount of 
editing to reduce the effort required to recover from the inevitable typo’s that occur during text entry. Line editing 
is an operating mode of Terminal Mode. Line editing should be enabled when direct human entry is used, and 
disabled when automated entry is used. 


e Line editing is enabled or disabled via an option in the serial/modem configuration parameters. 


e Enabling line editing disables input time-outs. 


e When line editing is enabled, echo should also be enabled. 


e When line editing is enabled, the Serial/Modem Connection Active (Ping) message should be disabled. 
Otherwise, unrequested Ping messages will appear in the data stream. 


e The <backspace> or <delete> key can be used to delete the last character entered. 
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e The <ESC> character can be used to delete the entire message. An <ESC> (1Bh) character received by the 
BMC immediately flushes any pending input message data. If line editing is enabled, and the <ESC> is 
followed by an input newline, the BMC responds by putting out an output newline sequence (typically <cr- 
If>). Otherwise, the BMC just silently flushes the data and goes back to looking for a START character. 


e = Any illegal characters received after the START character will silently flush the message in progress. The 
difference between this and <ESC> is that 


e Long IPMI message lines can be split across multiple lines by using a line continuation <backslash> character 
following immediately by the input newline sequence. 


e Line continuation character support is optional for the text commands, because they’re considered to be short 
enough to fit one line. 


e Line continuation character support for OEM messages is an implementation option. 


14.9 Terminal Mode Input Restrictions 
The following restrictions and characteristics apply to terminal mode: 


e Up to 80 printable characters are required to be supported for one line. The BMC can stop accepting new 
characters and stop echoing input when the 80 character limit is reached (with the exception of the <ESC>, 
<backspace>/<delete>, illegal character, and input <newline> characters, which will still be handled). 


e The interface must support the maximum IPMI input message length that is supported on the given BMC. Per 
Section 6.14, Message Size & Private Bus Transaction Size Requirements, this will typically be 40 bytes. 
Since each message byte can require three input characters (two hex-ASCII digits, plus a <space> character) 
a 40-byte IPMI message could require 120 characters, plus the starting and ending brackets, or 122 
characters, total, for the message. 


14.10 Page Blackout Interval 


The Page Blackout interval determines the minimum number of minutes between successive pages. The purpose 
for this parameter is to provide a mechanism to prevent someone from getting back-to-back pages if a flurry of 
events occurs. The interval applies to Dial Pages and TAP Pages. It does not apply to Dial-out PET Alerting. 


The Page Blackout Interval does not turn off Platform Event Filtering or associated actions. Platform Event 
filtering continues while a page or blackout interval is in progress. The BMC will accumulate the set of pending 
actions that occur during the page and blackout interval. If an event triggers a power-down action, the page will be 
aborted, the power-down will occur, and the page restarted after the power down. If a reset or power-cycle action 
is triggered, that action will be held off until the paging process and blackout interval have concluded. 


The Page Blackout Interval setting is kept in the serial/modem configuration parameters managed by the BMC. 


14.11 Dial Paging 


Dial Paging is accomplished by the BMC using the dialing capabilities of an external modem to connect to a 
paging service and enter a page using telephone numeric keypad numbers. Once a connection is established, the 
BMC delivers the specified Alert String from the PEF Configuration Parameters to the modem. The paging string 
directs the modem to deliver a fixed number to the paging service. The paging string is often used to deliver the 
phone number of the system that is generating the alert. An administrator receiving the string can then call the 
system with a management application and use IPMI messaging to retrieve system status, SEL entries, and other 
information about the alert. 
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14.11.1 Alert Strings for Dial Paging 


Modern modems deploying the modem ‘AT’ command set [TIA-602] contain character options associated with 
the dial command that utilize built-in call detection features of the modem. Thus, the call progress detection 
requirements on the BMC are greatly simplified. Though the majority of modems will support all of the 
following options, some are not mandatory in [TIA-602]. The modem’s documentation should be consulted to 
verify support for character options prior to configuring non-volatile dial strings. The Alert Immediate 
command can be used to test dial strings before committing them to non-volatile storage. 


The following character options can be used in the Alert String for a Dial Page. These options follow the 
modem dial command (default =" ATD’) issued by the BMC: 


P Dial using Pulse. Dialing digits after the ‘P’ will be sent using pulse dialing 
R Reverse Frequencies. Forces modem to dial out at the answer frequency 
S=n Dial pre-stored phone number, n 

T Dial using Tone. Dialing digits after the ‘T’ will be sent using touch tones 
W Wait for dial tone 

@ Wait for guiet (answer) 

å Pause (2 seconds) 

i Return to command mode after dialing 

! Flash the switch hook 


14.11.2 Dialing Digits 
Per [TIA-602] the dialing digits consist of the ASCII characters 0..9, *, #, A, B, C, and D. 


14.11.3 <Enter> Character (control-M) 


The BMC recognizes the “control-M” character (ODh) as an <ENTER> character. When the BMC encounters 
this character it transfers it to the modem and then delays | second before sending any remaining characters in 
the page string. Note that the BMC automatically issues an SENTER?” character after sending out the Dial 
String when performing a Dial Page. 


14.11.4 Long Pause Character (control-L) 


The BMC also recognizes the “control-L” character (OCh) as the trigger for generating a 10-second ‘long pause” 
sequence. When the BMC encounters this character, it doesn’t send it to the modem but instead delays 10 
seconds before sending any remaining characters in the page string. 


14.11.5 Empty (delimiter) Character (FFh) 


The BMC recognizes FFh in the page string as a ‘delimiter’ character used by BIOS. The character is provided 
as a potential aid to for interfaces, such as BIOS setup, that may split the page string into multiple fields for 
presentation to the user. The BMC ignores the character and does not transfer it to the modem. 


14.11.6 ‘Null’ Terminator Character (00h) 


The BMC recognizes this character as a terminator for the Dial String. This terminator is used whenever the 
Dial String data consists of fewer characters than the maximum length for the Dial String. Note that the BMC 
automatically issues an <ENTER> character after sending out the Dial String when performing a Dial Page. 


203 


Intelligent Platform Management Interface Specification 


14.12 TAP Paging 


TAP (Telocator Access Protocol) is a popular protocol for sending an alphanumeric page by connecting to a 
paging service using a serial modem. IPMI supports TAP as an option for delivering a short alert page to a remote 
paging service. This capability is referred to as TAP Paging. TAP Paging is triggered from the IPMI Platform 
Event Filtering capability. It can also be triggered ‘manually’ via the Serial/Modem Connection Active (Ping) 
command. 


The protocol is described in the [TAP]. Per [TAP], there are two types of remote page entry: automated and 
manual. The TAP implementation for IPMI operates using the management controller as an automated entry 
device. 


A TAP Paging transaction consists of one or more blocks. A block can contain up to 250 characters of 
information. Each block contains one or more short message strings that form a message sequence. Message data 
can span blocks. The short message strings are also referred to as ‘Fields’ in the TAP specification. Since only a 
small number of characters are delivered in an IPMI TAP Page, only a single block will be transmitted. 


There are typically two fields within the first block. The first field, Field #1, is called the Pager ID field. Some 
paging services refer to this as the PIN (Pager ID Number). This field is used to identify the target pager. The 
second field, Field #2, is the alphanumeric paging message. TAP only directly supports delivery of 7-bit ASCII 
characters. There is an associated protocol for transmitting 8-bit characters via TAP, but that protocol is not 
supported in this specification. 


TAP includes provision for an optional alphanumeric six-character password for the paging service. The password 
is also set via the serial/modem configuration parameters. 
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Appendix F - TAP Flow Summary, presents an additional overview and implementation notes for TAP paging via 
a BMC. 


14.12.1 TAP Escaping (data transparency) 


TAP allows ASCII control characters (00h to 20h) to be sent in the alphanumeric paging transaction as two- 
character sequences. TAP requires that the characters be escaped per the following table. The BMC 
automatically performs escaping when transmitting TAP messages. 


Table 14-, TAP Escaping 


Character value Escaped as: Escaping mandatory? 
<EOT> 04h 1Ah, 44h yes 
<STX> 02h 1Ah, 42h yes 
<ETX> 03h 1Ah, 43h yes 

<LF> OAh 1Ah, 4Ah yes 
<CR> ODh 1Ah, 4Dh yes 
<ETB> 17h 1Ah, 57h yes 
<SUB> 1Ah 1Ah, 5Ah yes 
<ESC> 1Bh 1Ah, 5Bh yes 
Other Control Characters - 1Ah, (value + 40h) optional 
e.g. 20h > 1Ah, 60h 


[TAP] states that “any [optional] control character may be made transparent at the implementor’s discretion”. 
The IPMI serial/modem configuration options for TAP paging include a control-character map similar to that 
used in PPP so that the user can configure which control characters get escaped for delivery to a particular TAP 
service. 


14.12.2 TAP Checksum 


TAP messages include their own checksum format. The checksum is transmitted using three printable ASCII 
characters. Refer to [TAP] for the checksum algorithm. 


14.12.3 TAP Response Codes 


Per [TAP], each handshake message that is returned from the paging service is specified to start with a 3- 
character response code. The values for these codes are specified in [TAP]. The implementation can optionally 
return a set of the last TAP Response Codes using the Get TAP Response Codes Command as an aid to TAP 
connection setup and debugging. 


14.12.4 TAP Page Success Criteria 


The management controller can use the TAP response codes to determine whether a page was successfully sent 
or not. One of the following response codes, received after the management controller sends an *End-of- 
Transaction’ <ETX> sequence, are used a positive indication of a successful page. Optionally, the page can be 
considered successful if an <ACK> is received following the end-of-transaction. The serial/modem 
configuration parameters include a setting that selects which of these confirmation mechanisms is used. 


Table 14-, TAP Success Codes 
code | TAP Definition 


211 Page(s) Sent Successfully 
213 Message accepted - held for deferred delivery. 
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14.13 PPP Alerting 


PPP Alerts are accomplished by the BMC connecting to a remote LAN via a PPP account and then delivering a 
UDP Datagram that contains an SNMP Trap formatted per the IPMI Platform Event Trap (PET) Format 
specification. Information for the PET trap comes from the Event Message that generated the alert and from the 
serial/modem configuration parameters for PET. 
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15. Serial Over LAN 


Serial over LAN (SOL) is the specification of packet formats and protocols for transmitting serial data over LAN 
using IPMI over LAN packets. The typical goal of this capability is to redirect the traffic to/from a local 
asynchronous serial controller interface. This enables communication over LAN with local software that only 
understands how to communicate through a local serial controller. This can be used for implementing a virtual 
remote serial terminal for enabling the user or remote software interaction with serial-based interfaces for operating 
systems (e.g. “command-line” interfaces and Linux console) and management services (e.g. Microsoft’s serial-based 
Emergency Management Services (EMS)). 


15.1 System Serial Controller Requirements 


The IPMI specifications do not set any mandatory requirement on the system-side interface for the serial 
controller used with Serial over LAN. A “16550” serial controller register set interface is expected to be the most 
common implementation. (Note that other specifications, such as EMS, may also have requirements for using a 
16550 or 16450 register set). It is required that the system serial controller makes the functions of the RS-232 
serial hardware handshake signals (RTS, CTS, DCD/DSR, DTR) available to the BMC. These do not need to be 
physical external signals as long as the BMC has the ability to perform the same flow control and set the same 
serial controller status that would be set as if the serial controller were connected to an external terminal via RS- 
232. 


15.2 SOL and Serial Port Sharing 


Serial-over-LAN has been designed to be able to work alongside the Serial Port Sharing capability of IPMI. This 
supports an implementation where traffic to/from the serial controller interface on the baseboard can be routed either 
to the BMC, SOL, or to the system’s serial port connector. To accomplish this, the specifications define commands to 
control the routing of the serial stream using the serial multiplexer logic, also referred to as the ‘mux’. Table 15-, Mux 
Settings describes the basic connections that support Serial-over-LAN. When Serial Port Sharing is used with SOL, 
the mux has three settings: 


Table 15-, Mux Settings 


| Setting | Deseripton [| 


System | The mux connects the serial connector on the chassis to the system serial controller. The RxD line is 
routed so the BMC can snoop incoming serial traffic for escape sequences and character patterns. 


BMC The mux connects the serial connector on the chassis to the BMC. The mux circuitry also places the 
hardware handshake lines to the baseboard serial controller into a steady state. 
SOL 


SOL | The mux is set to connect the baseboard serial controller directly to the BMC. 


Note that there is no requirement that SOL is used with serial port sharing. SOL can be implemented with a dedicated 
serial controller interface where the interface only provides traffic for SOL connections. Serial Port Sharing can be 
implemented on a separate port if desired, or not at all. 


The IPMI specifications do not specify the hardware design and implementation of SOL or Serial Port Sharing. Figure 
15-, SOL with Serial Port Sharing, presents an example block diagram for the purposes of illustrating the concept of 
SOL when used with Serial Port Sharing. 


The example figure shows the signal routing when the mux is set to ‘SOL’. The bold lines represent the flow of data. 
The interconnections and blocks shown are to illustrate the functional relationships between the system management 
elements, and do not map directly to the exact circuit implementation of the architecture. 


When the mux is set to ‘SOL’, the serial connection at the back of the box is isolated from both the baseboard serial 
controller and the BMC and the serial connector cannot be used for communicating with the BMC or the system. 
However, when SOL is not in use, the BMC can allow the serial connector to be used for functions such as the 
communicating with the BMC via IPMI over Serial, or as a regular serial port. 
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Refer to Section 15.12, SOL Interaction with Windows.NET Escape Sequences, and Section 15.13, SOL Payload 
Activated with Serial Port Sharing for additional information on the interaction between SOL and Serial Port Sharing. 


Figure 15-, SOL with Serial Port Sharing 
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15.3 SOL Operation Overview 


SOL operation is conceptually straightforward. Å remote management application can establish an IPMI-over- 
LAN session with the BMC. Once the session is established, the remote console can request that the SOL be 
activated. If SOL is used with Serial Port Sharing, this causes the BMC to set the mux to ‘SOL’. 


From this point, any outgoing characters from the baseboard serial controller are assembled into packets by the 
BMC and sent to the remote console over the LAN. Conversely, in-bound LAN packets carrying characters for 


the system serial controller have their character data extracted by the BMC and delivered to the baseboard serial 
controller. 
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The SOL character data is carried as SOL Messages that are carried in UDP datagrams. The packet format is that 
for IPMI v2.0 RMCP- with the Payload Type set to “SOL”. The SOL Payload includes fields that are used for 
supporting acknowledge and retries of SOL messages, and for supporting functions such as flushing buffers or 
temporarily suspending serial traffic using flow control. 


15.4 SOL Security 


Authentication and encryption for SOL are handled at the RMCP- level. 


15.5 SOL Sequence Numbers 


At the session level, SOL Payloads share the session seguence numbers for authenticated and unauthenticated 
packets with other packets under the IPMI session. At the payload level, SOL packets include their own message 
sequence numbers that are used for tracking missing and retried SOL messages. 


15.6 Flow Control 


Flow Control is used to help ensure that serial data is not lost because of differences in the throughput between the 
serial controller interface and the network interface. When SOL is used with a physical serial controller, flow 
control on the serial controller side is accomplished by the BMC controlling and monitoring the hardware 
handshake signal lines (RTS, CTS, DCD/DSR, DTR) on the serial controller. 


Some implementations may have the serial controller function integrated into the BMC or another device. Such 
implementations may not have physical hardware flow control lines, but there must be internal control capabilities 
that accomplish the same thing. 


Flow control on the network side is handled by use of acknowledges (ACKs) and negative-acknowledges 
(NACKs) that indicate whether the BMC is ready to accept more data or not. 


15.7 Bit Rate Handling 


Some implementations of SOL will connect pins for a serial interface on the BMC to the pins for the serial 
interface of a serial controller for the system. For standard microcontroller serial interfaces, the BMC would need 
to know the bit rate setting of the motherboard serial controller in order for the BMC’s serial controller to be in 
synch. Thus, there is a non-volatile configuration setting for setting the bit rate for SOL in the BMC. 


Other implementations may incorporate an embedded serial controller in the BMC or may have hardware 
mechanisms that allow the BMC to get the bit rate setting directly from the system serial controller. In this case, 
the non-volatile configuration bit rate setting is not used. 


15.8 Volatile and Non-volatile SOL Configuration Parameters 
SOL configuration parameters may be volatile, non-volatile, or have both volatile and non-volatile settings. 


Unless otherwise specified, the volatile settings are copied from the non-volatile settings when the BMC first 
initializes. Subsequently, the non-volatile settings are restored whenever the payload is first activated. 


Unless otherwise specified, changes to volatile parameters take effect immediately (within normal command 
processing time, typically ~30 milliseconds) and for the duration that the payload is activated. For example, 
changing the bit rate of SOL using the non-volatile setting will cause the BMC to immediately change its bit rate 
setting. 


It is desirable that some volatile settings, such as bit rate, take effect before communication proceeds on the 
channel. To help support this, the Activate Payload command includes an auxiliary parameter that enables the 
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remote console to direct the BMC to leave CTS and DCD/DSR deasserted after the payload has been activated. 
Assuming the baseboard serial controller is paying attention to hardware handshake, this enables the remote 
console to hold off character transmission from the baseboard until it has changed volatile settings. 


15.9 SOL Payload Data Format 


Table 15-, SOL Payload Data Format, specifies the fields that make up the SOL Payload in an RMCP+ packet. 


Table 15-, SOL Payload Data Format 


Field 
Packet Sequence 
Number 


Size 


Description 
Sequence Number for this packet. 


Sequence numbers must be non-zero. Multiple outstanding sequence numbers are 
not supported in this version of the specification. Retried packets use the same 
sequence number as the first packet. 


[7:4] 
Reserved 
[3:0] 
Packet sequence number. Oh = ACK-Only packet. 


Packet ACK 
/NACK Sequence 
Number 


Sequence Number for packet being ACK’d or NACK d. 
[7:4] 
Reserved. Write as Oh. 
(Future spec may use this to specify a range of packets being acknowledged) 


[3:0]: Packet sequence number being ACK’d/NACK’d. 
Oh: Informational packet. No request packet being ACK’d or NACK d. 


Accepted 
Character count 


Accepted Character Count 1-based. 

This field indicates the number of characters accepted from the packet, if any. 
00h = Packet received but no data bytes accepted. 

For BMC-to-Console: 


In order to improve throughput, the BMC is allowed to append additional characters 
to a packet when it resends it. To support this, the remote console must accept 
retried packets (packets with the same packet sequence number) and check to see 
if the packet contains additional data. If the packet does contain addition data, the 
remote console should accept the data and acknowledge the packet using the 
packet sequence number and return the count of the number of characters that it 
had received. 


The console must either accept all packet data sent to it or NACK the entire packet. 
It is not allowed to accept partial packet data. 


For Console-to-BMC: 


The BMC is allowed to accept partial packet data by NACK’ing the packet and 
returning a character offset that is less than the data length sent by the remote 
console. The remote console would then send the next packet starting with the first 
byte of data that the BMC rejected. Retried packets from the remote console are 
unchanged from the original packet. The remote console is not allowed to append 
additional data to retried packets. This eliminates the need for the BMC to check 
the content of packets with duplicate packet sequence numbers. 


Operation / Status 


BMC to Remote Console: Remote Console to BMC: 
Operations are executed before Note: Operations are executed before 
character data is transferred. character data is transferred. 

[7] reserved [7] reserved 
[6] [6] ACK/NACK 
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Field 


Size 


Description 


1b: Packet is being NACK’d. The 
BMC is unable to accept all 
character data from packet. 
Note: Operation field is still 
accepted even if packet is 
NACK’d. 


Ob: ACK. BMC ready to accept next 
packet of character data. 

GIN 
A NACK packet with this status will 
be automatically sent one time after 
this bit changes state. (Whenever 
the system enters or leaves a power 
state where character transfers to 
the system serial controller are 
possible) 


A NACK packet with “Character 
transfer is unavailable” status will 
also be sent for each character 
transfer request from the remote 
console when the system is ina 
powered-down or sleep state. 


1b: Character transfer is 
unavailable because system is 
in a powered-down or sleep 
state. 


Ob: SOL character transfer is 
available. 

Kk 
A NACK packet with this status will 
be automatically sent one sent 
once, just before the BMC 
deactivates SOL because of a front 
panel power-button or a reset. 


1b: SOL is deactivated/deactivating. 
[Remote console can use this to 
tell if SOL was deactivated by 
some other party, or by local 
pushbutton reset or power 
on/off]. 


Ob: SOL is active. 
[3] Transmit Overrun 


1b: characters were dropped 
between transmitting this packet 
and the previous packet, 
because the system did not pay 
attention to hardware flow 
control. 


Ob: no characters were lost between 
this packet and the preceding 
packet. 

[2] Break 

1b: A break condition from the 
system has been detected. The 
BMC will generate this only on 


1b: NACK. Packet is being NACK’d by 
the remote console. 


Ob: ACK. Packet is being ACK’d by 
the remote console. 
[5] Ring/WOR 
Assert RI (may not be supported on all 
implementations) - Goal is to allow this 
to be used for generating a WOR. 
[4] Break 
1b: Generate BREAK (300 ms, 
nominal) 
[3] CTS 
1b: Deassert CTS (clear to send) to 
the baseboard serial controller. 


(This is the default state when 
SOL is deactivated.) 


Ob: If test mode = inactive, Let BMC 
control CTS. If test mode = active, 
assert CTS. 


[2] DCD/DSR 
for test mode = inactive: 


1b: Deassert DCD/DSR to baseboard 
serial controller 


Ob: Assert DCD/DSR to baseboard 
serial controller. 


for test mode = active: 


1b: Deassert DCD to baseboard serial 
controller 


Ob: Assert DCD to baseboard serial 
controller. 


[1] Flush Inbound 
for test mode = inactive: 


1b: Drop (flush) data from remote 
console to BMC [not including 
data carried in this packet, if any] 


for test mode = active: 


1b: Deassert DSR to baseboard serial 
controller 


Ob: Assert DSR to baseboard serial 
controller. 


[0] Flush Outbound 
for test mode = inactive: 


1b: Flush Outbound Character Data 
(flush data from BMC to remote 
console) 


for test mode = active: 
reserved. Write as Ob. 
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Field Size Description 
one packet at the start of the 
break. 
Ob: no break detected 
[1:0] For test mode = inactive: 
Reserved 
For test mode = active: 
[1] - 1b = RTS asserted 
[0] - 1b = DTR asserted 
A packet with this status will be 
automatically sent whenever RTS or 
DTR changes state. Note that this 
packet may not contain character 
data. If no character data is available, 
this will be a NACK packet. 


Otherwise, the ACK/NACK state 
follows the definition for bit [6], above. 


Character Data varies | Data length, in bytes, is equal to the IPMI Message/SOL Message Length field in 
the Session Header, minus the bytes for the Packet Sequence Number, through 
and including the Operation Field. 


1. If the system is powered down or in certain sleep states, the baseboard serial controller will not be available for transferring 
characters. When the BMC receives data from the remote console, and the system is powered down or sleeping, the BMC can 
use this bit to return status to indicate to the remote console why the characters it received may not be able to be transferred to 
the system. Note that this is an ‘advisory’ bit. The BMC will still attempt to put characters into the system serial controller in 
case that the serial controller is configured to wake the system under this condition. It is mandatory that the BMC returns this 
bit when the system is powered down (S4/S5). The BMC may not be able to differentiate other system sleep states, in which 
case the bit should be returned as Ob (transfers available). If the SOL payload is launched over a separate or dedicated 
session, the device managing that session may not be able to tell when the system is powered down. In this case, the 
‘character transfer is unavailable’ function of this bit is optional, but recommended. 


2. The BMC issues this status when the payload is deactivated for due to the following conditions: a. The payload is deactivated 
because of a manual power down or reset. (An implementation is recommended to have a local manual “pushbutton” reset or 
power-off to deactivate an SOL payload. This is provided as a way of terminating remote control connections for local 
servicing.) b. The SOL payload is deactivated via the Deactivate Payload or Close Session commands. These command may 
have been issued from another session. (System software operating through the system interface, and users with Admin 
privilege have the ability to issue the Deactivate Payload and Close Session commands to other sessions). If the SOL payload 
is launched over a separate or dedicated session, the device managing that session may not be able to tell whether the system 
is being locally powered on/off or reset. In this case, the ‘SOL de-activating’ function of this bit on local power and reset 
transitions is optional, but recommended. 


15.10 Activating SOL using RMCP+ Authentication 


To use SOL a remote console or remote application must first establish an IPMI Session with the BMC. This is 
accomplished by sending the specified IPMI and RMCP+ RMCP+/RAKP messages to the BMC with the 
appropriate user name, role, and password/key information. If the remote console plans to use encryption with 
SOL, the console must also negotiate an encryption algorithm at the time that the IPMI session is established. 


Once the IPMI session has been established, the Get Channel Payload Support command can be used to retrieve 
the present availability of SOL and the version of SOL. 


If SOL is not already active on another session, the next step is to issue the Activate Payload command. The 
command will return information about what serial input and output data buffer sizes are available on the BMC as 
well as the UDP port number over which SOL packets can be transferred. 


The port that was used for establishing the IPMI session may not be the same port number that SOL is available 
over. Some implementations transfer SOL payloads available over a separate UDP port in order to provide better 
performance. If the Activate Payload command returns a port number that is different than the port number that 
was used to establish the IPMI session, the remote console must establish a separate IPMI Session to the specified 
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port number using the same IP Address, username and password/key information that was used to establish the 
IPMI session. 


Note that if a second session has already been established on that port number for a different payload type, the 
existing session can also be used for SOL payloads, provided that the session was established at a privilege level 
that matches the privilege level and authentication required for SOL. Otherwise, the remote console will need to 
close that session and re-establish it at the necessary privilege level. 


15.11 SOL Packet Acknowledge and Retries 


A packet acknowledge is of one of two types: 
e An ACK, indicating that the packet has been received and all its data has been accepted 
e A NACK, indicating that the packet was received but some or all of the data could not be accepted 


To improve efficiency, the packet acknowledgment information can be carried in a packet that also carries the 
SOL character data. Conversely, a packet can be an ACK-only packet that carries ACK or NACK information, 
but no data. Packets with a Oh Packet Sequence Number are not acknowledged. Therefore, ACK-only packets , 
which are specified to have a Oh Packet Sequence Number, are not acknowledged. 


Except for ACK-only packets from the BMC, the remote console must acknowledge each SOL packet that it 
receives. If the BMC does not receive an ACK packet within a timeout interval, the BMC will resend (retry) the 
packet. The number of retries and the amount of time between retries are configurable through the SOL 
Configuration Parameters. Once the number of retries has been met the BMC will drop the packet and the data 
will be lost. Similarly, the BMC will acknowledge all packets it receives from the remote console that have a 
non-Oh Packet Sequence Number. Le the BMC acknowledges all packets except ACK-only packets from the 
remote console. 


If the remote console wants to temporarily stop the BMC from accepting characters from the system, it should use 
the “CTS Pause” bit in the control/status byte. Whether this stops the system from transmitting is dependent on 
whether the system software pays attention to the CTS (hardware handshake) status or not. If the system continues 
to send characters to the BMC, the BMC will attempt to transmit them to the remote console. 


It is possible that additional characters could be received from the system serial controller while the BMC was 
waiting for a retry timeout. In order to improve throughput, the BMC is allowed the option of appending 
additional characters to a packet whenever it resends it. To support this, the remote console must accept retried 
packets (packets with the same packet sequence number) and check to see if the packet contains additional data. If 
the packet does contain addition data, the remote console should accept the data and acknowledge the packet 
using the packet sequence number and character offset value that it had received. 


Table 15-, Remote Console to BMC SOL Packet Handling 


Packet fields from remote console: Function / BMC Action 
ACK/ ACK’d/NACK’d Accepted 
NACK Seq# Character Count 
ACK Seq # from BMC data Non-zero “Completion ACK” 
packet matches character BMC processing for specified packet is done. 


count from BMC 
A packet from the remote console with an ACK and an 
Accepted Character Count for the full amount of data 
for the packet indicates that the remote console has 
successfully accepted the packet. 

ACK Seq # from BMC data Non-zero “Partial ACK” 

packet less than character BMC immediately retransmits specified packet 

count from BMC 


It is possible that the remote console may have missed 
a BMC retry where the BMC had appended more data 
to the packet (retry intervals should be configured to 
avoid this scenario). If the BMC receives an ACK for 
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less than the last amount of transmitted data, the BMC 
will cease appending data to the packet and will 
retransmit the packet until it receives an ACK from the 
remote console with an Accepted Character Count for 
the full amount of packet data. 

NACK Seq # from BMC data 0 “Suspend NACK” 

packet BMC stops sending specified packet. 


The remote console would use the Suspend NACK if it 
were temporarily out of buffer space for characters 
already queued up in the BMC and did not want those 
characters to get dropped. The BMC stops sending / 
retrying specified packet and waits until it gets either a 
“Partial ACK”, “Completion ACK”, “Resume ACK” or a 
Flush Outbound operation from the remote console. 
The BMC will deassert CTS when it gets near running 
out of buffer space for characters from the system. If 
characters continue to come in (CTS is ignored by the 
system) a transmit overrun condition can occur. 


ACK Seq # from BMC data 0 “Resume ACK” 
packet BMC immediately retransmits specified packet. 
Cancels a “Suspend NACK”. 


A packet from the remote console with an ACK and an 
Accepted Character Count of zero (0) bytes will cause 
the BMC to immediately retransmit the packet with the 
corresponding sequence number to the remote 
console. This can be used as a way to get the BMC to 
restart transmission after a Suspend NACK from the 
remote console. 

ACK Oh 0 “Control-only Packet” 

BMC performs operation specified in the control/status 
field. 


For FLUSH operation: 

A packet from the remote console with a “Flush 
Outbound’ operation will cause the BMC to cease any 
retries in progress and the BMC will start accumulating 
character data anew. The remote console can use this 
as a recovery mechanism if it gets ‘lost’ in the 
sequence from the BMC. 


See packet format table for info on other functions. 


15.12 SOL Interaction with Windows.NET Escape Sequences 


The Microsoft INET Emergency Management Services specification (See [MSFT EMS]) defines certain character 
sequences for performing the following operations: 


System Hard Reset <ESC>R<ESC>r<ESC>R 
Invoke Service Processor (i.e. switch to BMC) <ESC>( 

Exit Service Processor (with optional prompt) Q 

Exit Service Processor (without confirmation prompt) <ESC>Q 


The specification also requires that a switch to the Service Processor is acknowledged by sending an <ESC>* 
sequence to the remote console: 


Acknowledge Switch to Service Processor <ESC>* 


Typically, the input escape sequences would be received by the BMC over the serial/modem connection. In this 
case, the sequences for Invoking and Exiting the service processor would control the serial/modem mux setting 
associated with serial port sharing. However, there are separate streams for SOL and BMC traffic, so unlike serial 
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port sharing there is no need for a mux to switch between console traffic to the system serial controller and traffic 
to the BMC. 


Therefore, since you can always send commands to the BMC as IPMI Messages, the BMC itself does not snoop 
for or handle Windows .NET Escape sequences in the SOL character data. However, a remote console application 
can emulate support for the Windows .NET headless sequences by filtering for the Windows .NET escape 
sequences prior to placing the data in an SOL packet. If the Windows .NET escape sequences are detected, the 
remote console can then take the appropriate actions. For example, if the Reset escape sequence is detected, the 
remote console would send the IPMI command for a system reset. 


15.13 SOL Payload Activated with Serial Port Sharing 


The following lists the behavior of certain IPMI commands while SOL is activated. This applies only when the 
SOL is being used in conjunction with Serial Port Sharing. 


The Set Channel Access command is accepted for the serial channel, but while SOL is activated the 
Channel Access Mode is forced to ‘disabled’. Attempting to change the access mode while SOL is 
activated will result in a D5h completion code. The access mode shall be saved when SOL is activated, and 
restored when SOL is deactivated. 


The Set Serial/Modem Configuration Parameters and Get Serial/Modem Configuration Parameters 
commands are accepted for the serial/modem channel and have no special behavior while SOL is activated. 


The UDP proxy commands, Set PPP UDP Proxy Transmit Data, Get PPP UDP Proxy Transmit Data, 
Send PPP UDP Proxy Packet, Get PPP UDP Proxy Receive Data, will receive a D5h error completion 
code while SOL is activated. 


The Callback command will receive a D5h error completion code when the command is targeted to the 
serial/modem channel being used for SOL and SOL is activated. The Set User Callback Options and Get 
User Callback Options commands will be accepted. 


The Send Message Command will receive a D5h error completion code when the command is targeted to 
the serial/modem channel being used for SOL and SOL is activated. 


The Alert Immediate Command will receive a D5h error completion code when the command is targeted to 
the serial/modem channel being used for SOL and SOL is activated. 


While SOL is activated, the Set Serial/Modem Mux command will respond to the requested operations as 
follows: 


Table 15-, Set Serial/Modem Mux Command Operation while SOL Active 


Rejected (see response data for command 
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16. Event Messages 


Event Messages are special messages that are sent by management controllers when they detect significant or 
critical system management events. This includes messages for events such as ‘temperature threshold exceeded’, 
‘voltage threshold exceeded’, ‘power fault’, etc. The Event Message generator (the device generating an Event 
Message) notifies the system of the event by sending an “Event Request Message” to the Event Receiver Device. 


When the Event Receiver gets a valid Event Message, it sends a response message to the generator of the Event 
Message. It then typically transfers the message to the System Event Log. The Event Receiver does not interpret the 
Event Messages it receives. Thus, new Event Message types can be added into the system without impacting the 
Event Receiver implementation. 


In some systems, the Event Receiver will need to interrupt the system to notify it that there is an Event Message to 
be logged. It is desirable for the implementation to have verified and buffered Event Messages in their entirety 
before issuing such an interrupt. This way, the interrupt handler will not need to wait for the Event Message 
transmission to complete first. 


16.1 Critical Events and System Event Log Restrictions 


The platform’s System Event Log is typically of limited size (~3 to ~8 KB, depending on implementation). 
Therefore, it is important to refrain from filling the System Event Log with non-critical ‘clutter’. 


The System Event Log is primarily intended for capturing Critical Events. These include events that require 
immediate logging to guarantee that they’re available for ‘post-mortem’ analysis, and events that may require 
quick system responses, such as system power off, or shutdown. 


Critical events include out-of-range temperature and voltage events, hardware failures such as power supply or 
fan failures, interrupts and signals that affect system operation such as NMIs and PCI PERR (parity error) and 
SERR (system error). Critical Events also include events that impact system data integrity, such as the 
uncorrectable ECC errors, or system security, such as ‘chassis intrusion’. 


In addition to events that indicate ‘failure’ conditions, events that indicate impending failures are also considered 
to be critical events. This includes events for reaching ‘warning levels’ for things such as system temperature or 
error counts. The assertion of ‘Predictive Fault’ information is also considered critical, particularly if the 
monitored device does not have a direct ‘failure’ indication. 


Non-critical events, such as the return to an ‘OK’ state from a ‘Warning’ state should not be sent as critical 
events. Non-critical system information is normally obtained by System Management Software polling sensors 
and management controllers for their status. 
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Table 16-, Event Message Reception 
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The preceding figure presents a conceptual illustration of the manner in which Event Messages can be handled by a 
Baseboard Management Controller device that uses an external non-volatile storage device to hold the System Event 


Log. 


The figure shows a BMC with a shared system messaging interface where Event Messages can be delivered from 
either BIOS, SMS (system management software / OS), or an SMI Handler, and an IPMB interface and through 
which it can receive Event Messages from the Intelligent Platform Management bus. The BMC can also generate 
‘internal’ Event Messages. 


When the BMC receives a message via the system or IPMB interfaces, a ‘Message Handler’ function recognizes the 
message as being for the ‘Event’ functionality in the BMC and passes the message information on to the ‘Event 
Receiver’ function. The Event Receiver function then takes the message content and issues a request to a ‘SEL 
Mer.’ function that formats the message as an SEL Entry and calls the FLASH Interface to have the data stored. 


The Event Receiver function is also responsible for driving the response message back through the messaging 
system. This way, message acknowledgment or error reporting can be provided. 


16.2 Event Receiver Handling of Event Messages 


This section presents some implementation advice for the Event Receiver device. Please refer to the Intelligent 
Platform Management Bus Communications Protocol Specification for additional information on Event Message 


handling. 


Since retries of Event Messages are part of the IPMB protocol, there is the potential for the Critical Event Handler 
to receive more than one Event Messages for the same event. The Seq field allows repeated Event Messages to be 
discriminated from new Event Messages. Event Messages from a Event Generator that match an earlier Event 
Message can be ignored. 


The option to disable SEL Logging only affects events that are received from the IPMB and PCI Management 
Bus interfaces. Devices on the IPMB and PCI Management Bus are more likely to generate events ‘automatically’ 
while the other interfaces are primarily driven by either local or remote software which is assumed to have more 
control as to whether it generates events or not. 
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It is recommended that Event Receiver keep a table or queue of the Event Messages it has received. Any new 
event message from the same source and of the same type, but with a different sequence number, would replace 
the previous entry. 


There are many ways to implement such a table or queue. Any implementation should provide enough tracking 
support to handle previously received Event Messages for all the ‘known’ Event Generators in the basic system. 
For example, a system that has four management controllers on the IPMB that can generate Event Messages 
should track the previously received Event Messages from those devices. 


It is desired that the Event Receiver can track at least six additional Event Generators to cover additional Event 
Generators that are added into the system. (One common add-on would be an emergency management. Other 
possible ‘add-on’ event generators would be other systems and peripheral boxes in a “managed cluster” 
arrangement). 


The Event Receiver implementation should account for the possibility that there can be more different Event 
Generators than there are slots in the table. This can be managed by implementing the table with an ‘LRU’ 
deletion algorithm, where the oldest tracked Event Messages are deleted if a new Event Message comes in and the 
table or queue is full. It can be assumed that there will rarely be more than two event messages that would be in 
the state where they are to be re-transmitted because of a lost acknowledge. 


With this type of design, the most anomalous behavior would be the multiple recording of the same event. This 
would only be seen under artificially generated ‘stress’ testing and would only be able to occur if there were more 
event message sources than table slots. 


It is also recommended that the Event Receiver implement the ‘Seq Timeout’ as specified in the IPMB 
Communications Protocol specification. 


16.3 IPMB Seq Field use in Event Messages 


This section presents a review of the IPMB Seq field and the manner in which it is used when Event Messages are 
delivered via the IPMB. 


The Event Receiver uses the Seq field to reject retried (duplicate) Event Request Messages that it may receive. 
The Event Generator will re-send an Event Request Message if it does not receive the Event Response Message. It 
is possible that the response could get corrupted, causing the Event Generator to re-send the original request even 
though the Event Receiver had already successfully received it. This is one way that an Event Receiver could get 
more than one Event Request Message for the same event. When the Event Generator re-sends the Event Request 
Message, it does so with the same Seq value that it used for the original try. The Event Generator will increment 
the Seq value the next time it has a new Event Request Message to send. 


When Event Messages are delivered via the IPMB, the IPMB message’s Seq field is used to allow Event Receiver 
to discriminate whether the Event Message is for a new occurrence of a given event, or is a re-transmission of a 
previous Event Message for that event. The IPMB Seq field should not be confused with being a sequence number 
for tracking multi-message transfers, as might be its use in other serial protocols. 


If the Event Receiver receives an Event Message where the Cmd, NetFn, LUN, and Seq fields match the previous 
event message from the same Requester, it can assume that the latter message is a re-transmission and return a 
‘normal completion’ (00h) as a response to valid, duplicated requests. The Event Receiver does not log duplicate 
events. 


If the Event Receiver does not return a response, the Event Generator retries up to its retry limit count and then 
concludes that the Event Request failed. Event Generator devices on the IPMB do not send new Event Messages 
until they’ve finished sending the previous Event Message (including retries). This eliminates the need for the 
Event Receiver to maintain status for multiple Seq numbers from a single Event Generator. 


The data fields for the Event Request Message are not included in the comparison. This is because the Event 
Request Message may return a data field that reflects a ‘present state’ or data value that could vary with each 


retry. 
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Refer to the Intelligent Platform Management Bus v1.0 Communications Protocol Specification for more 
information on the Seq field. 


16.4 Event Status, Event Conditions, and Present State 


A sensor tracks present state and Event Conditions. An Event Condition is that set of comparisons applied to the 
present state and previous state that produces a given Event Status. 


A management controller typically polls for Event Conditions. When it sees a condition become active, it updates 
the Event Status for the sensor. The process of updating the present state Event Status is referred to as Scanning or 
Sensor Scanning. 


The Event Status is those bits that are reported in the Get Sensor Event Status command. As long as scanning is 
enabled, the Event Status bits will be updated according to changes in Event Status. This is independent of 
whether Event Messages are generated on a given event. That is, turning off Event Message Generation for a 
particular state does not turn off scanning or updates of the Event Status. 


The Get Sensor Reading command returns State Bits reflecting the present state of the sensor. If the sensor is an 
*auto- re-arm’ sensor, these bits can also represent the Event Status if hysteresis is factored in. Thus, the Get 
Sensor Events command is optional for auto- re-arm sensors. An application uses the masks in the SDR to 
determine which bits reflect both current state and event status, and which bits reflect current state only. 


The condition that causes an Event Message to be sent is referred to as the 'Event Trigger’. The classification of a 
sensor indicates whether the corresponding event was discrete, or threshold-based. The sensor classification is 
part of the Event/Reading Type Code (see section 42.1, Event/Reading Type Codes). 


A reading/state unavailable (formerly “initial update in progress”) bit is provided with the Get Sensor Reading 
and Get Sensor Event Status commands to indicate to software that it must ignore the reading and/or state 
information because the BMC cannot obtain a valid reading and/or state information. This can occur in situations 
where the sensor is monitoring an entity that may or may not be present, such as with hot-swap devices. For 
example, if a sensor monitors the temperature of a hot-swap power supply, the reading/state unavailable bit can be 
used to indicate that no valid temperature reading is available because the power supply is not installed. The bit 
can also indicate when a reading or state is unavailable because a sensor is re-arming (see Section 16.6, Re- 
arming, below. 


16.5 System Software use of Sensor Scanning bits & Entity Info 


System software must ignore any sensor that has the sensor scanning bit disabled - if system software didn’t 
disable the sensor. This provides an alternate mechanism to allow the management controller to automatically 
adjust the sensor population without requiring a corresponding change of the sensor data records. For example, 
suppose the management controller has a way of automatically knowing that a particular temperature sensor will 
be absent in a given system configuration if a given processor is also absent. The management controller could 
elect to automatically disable scanning for that temperature sensor. System management software would ignore 
that sensor even if it was reported in the SDRs. 


Note that this is an alternate mechanism that may be useful in some circumstances. The primary mechanism is to 
use the Entity ID information in the SDRs, and combine that information with presence detection for the entity. 


If there is a presence detection sensor for a given entity, then system management software should ignore all other 
sensors associated with that entity. Some sensors have intrinsic support for this. For example, a sensor-specific 
Processor sensor has a ‘Processor Presence’ bit. If that bit is implemented, and the processor is absent, any other 
sensors and non-presence related bits associated with that processor can be ignored. If the sensor type doesn’t 
have an intrinsic presence capability, you can implement an ‘Entity Presence’ sensor. This sensor solely reports 
whether a given Entity is present or not. 
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16.6 Re-arming 


Re-arm refers to resetting internal device state that tracks that an event has occurred on the sensor. After a sensor 
is re-armed the device will re-check the event condition and re-generate the event if the event condition exists. 


If the event condition already exists at the time that the re-arm is initiated, then it is possible that the event will be 
regenerated immediately following the conclusion of the re-arm. The delay from the re-arming of a sensor to the 
regeneration of the event is device implementation dependent. A reading/state unavailable (formerly “initial 
update in progress”) bit is provided with the Get Sensor Reading and Get Sensor Event Status commands to help 
software avoid getting incorrect event status due to a re-arm. 


16.6.1 ‘Global’ Re-arm 


A device that receives a Set Event Receiver command shall ‘re-arm’ event generation for all its internal sensors. 
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17. ‘Platform Event Filtering (PEF) 


Platform Event Filtering (PEF) provides a regular mechanism for configuring the BMC to take selected actions on 
event messages that it receives or has internally generated. These actions include operations such as system power- 
off, system reset, as well as triggering the generation of an Alert. 


The BMC maintains an event filter table that is used to select which events trigger a page (or other action) and 
which actions to perform. Each time the BMC receives an event message (either externally or internally generated) 
it compares the event data against the entries in the event filter table. The BMC scans all entries in the table and 
collects a set of actions to be performed as determined by the entries that were matched. 


Event filtering is independent of Event Logging. That is, Event Logging and Event Filtering (and associated actions) 
are enabled/disabled independent of one another. 


17.1 Alert Policies 


When an Alert is triggered via PEF the alerting process is directed by an Alert Policy. An alert policy is a 
collection of one or more alert destinations. An alert policy can support a mix of different alert destination types 
and channels. For example, one policy could include LAN, dial page, and TAP alerts to different locations. The 
destinations in a policy are processed in sequence. Whether a given destination will be used or not can be 
configured to be dependent on whether the alert to the previous destination was successful or not. 


Alert Policy data is stored in an Alert Policy Table that is part of the PEF configuration parameters. An 
implementation can support multiple policies. A policy number identifies different policies in the table. The alert 
policy number is used in the Event Filter Entry to select what alert policy is used when a match occurs. This 
mechanism allows different alert policies to be associated with different classes of events. For example, one 
policy to be used for ‘high priority’ events and a different policy for ‘low priority’ events. 


Some alerts, such as alphanumeric pages, can be associated with Alert Strings. The combination of Event Filter 
Entry and alert destination are used to select a given Alert String from a set of strings kept in the PEF 
configuration parameters. This enables different strings to be sent based on what event filter was matched and 
where the alert is being sent. 


17.2 Deferred Alerts 


When an alert policy is initiated, it’s possible that the communication path to the destination could already be 
busy processing an earlier alert. To handle this situation, the implementation internally queues up information that 
tracks alert policies and destinations to be processed. Alerts that have been postponed are referred to as Deferred 
Alerts. 


A BMC that supports alerting is required to support deferred alert policies for at least eight events. 


17.3 PEF Postpone Timer 


Event logging takes precedence over PEF actions. That is, BMC logging of the event is completed prior to 
initiating any PEF actions. PEF can occur immediately after the event is logged, or it may be postponed by the 
PEF Postpone Timer. The PEF Postpone Timer is a separate timer that allows system software time to process 
events instead of PEF. PEF will occur if system software does not handle the event before the PEF Postpone 
Timer expires. 
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17.4 PEF Startup Delay 


Platform Event Filtering is active whenever the BMC is in a state to receive events, either internally or externally 
generated. This includes events received over the system interface. Platform Event Filtering is not available when 
the BMC is in manufacturing test, modal SDR update, or firmware update modes. 


PEF triggered actions may be postponed during certain intervals of BMC operation. The PEF Startup Delay 
causes Platform Event Filtering triggered power-down, reset, and power-cycle actions to be postponed when the 
system is either powered up or is reset locally via a pushbutton or other local ‘front-panel’ user interface. OEM 
actions may or may not be postponed, at the choice of the OEM implementation. Alerts are not postponed by the 
PEF Startup Delay. There is a separate, optional, PEF configuration parameter that can control whether Alerts are 
delayed on system startup. An implementation may allow the time delay for the PEF Startup Delay to be 
configured via the Set PEF Configuration Parameters command. 


It is recommended that the act of entering BIOS setup automatically disables Platform Event Filtering, and that 
exiting BIOS setup automatically restores the prior PEF enabled/disabled state (provided that the user does not 
explicitly change the PEF configuration while in setup). 


The combination of the delay and BIOS setup gives the user the opportunity to enter setup and disable PEF. These 
provisions are to allow recovery in case an incorrectly configured filter/action prevents the system from running 
by powering it off, power cycling, or resetting it whenever the BMC initializes. Disabling PEF must immediately 
cancel any pending PEF actions and deferred alerts. 


17.4.1 Last Processed Event Tracking 


A non-volatile ‘Last Software Processed Event’ storage location holds the Record ID for the last SEL Record 
that system software has processed. System software writes to that location to identify which records it has 
processed. A corresponding ‘Last BMC Processed Event’ value holds the Record ID for the last event in the 
SEL that the BMC processed. These values can be set and retrieved by software using the Set Last Processed 
Event ID and Get Last Processed Event ID commands, respectively. 


If PEF is disabled, the Last BMC-processed Event holds the Record ID for the last event that was received. 
Clearing the SEL automatically clears the Last Software Processed Event and Last BMC Processed Event 
values. 


If PEF is enabled and the BMC loses power or is reset before the PEF Postpone Timer expires, the BMC will 
automatically perform PEF against any existing, unprocessed events in the SEL once the BMC has restarted and 
reinitialized. 


Once enabled, the PEF Postpone timer starts running as soon as an unprocessed event is detected in the SEL. If 
the SEL already contains unprocessed events, the timer will start immediately. 


The timer does not automatically reset on events received while the timer is running, but is reset by system 
software after it sets the Last Software Processed Event value. 


17.5 Event Processing When The SEL Is Full 


If the SEL is full, new events will still be put into the Event Message Buffer (if the optional Event Message 
Buffer is implemented). The Event Message Buffer for IPMI v1.5 is not overwritten if new events come in. 
Therefore, if the Event Message Buffer is full, further events will not go into the event message buffer until its 
cleared. 


If PEF is implemented, events will also be accepted into a ‘hidden’ internal queue or buffer so they can be 
processed by PEF. That buffer is only required to hold a single event. Thus, if that internal buffer gets full, 
event messages will be rejected until a new space opens up. 
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If neither an Event Message Buffer nor PEF are implemented, events will be rejected by the BMC once the SEL 
gets full. 


An implementation is allowed to provide a proprietary ‘SEL Aging’ option that automatically clears out SEL 

entries if they’re more than a certain age old. If this is done, the algorithm must set the SEL ‘most recent erase 
timestamp’ to reflect the time entries were deleted. It must also be possible to configure the system to operate 
with the aging algorithm turned off. 


17.6 PEF Actions 


BMC will scan entire list, collecting a set of actions. Actions will then be executed in priority order. An alert 
action can occur in combination with any other action (in priority order). The power down, power cycle, and 
reset actions are mutually exclusive. If a combination of power down, power cycle, and/or reset actions results, 
only the highest priority action will be taken. 


Table 17-, PEF Action Priorities 


Action Priority | Additional Information 

power down 1 (optional) 

power cycle 2 (optional) Will not be executed if a power down 
action was also selected. 

reset 3 (optional) Will not be executed if a power down or 
power cycle action was also selected. 

Diagnostic 4 (optional) The diagnostic interrupt will not occur if a 

Interrupt higher priority action is also selected to occur. 

ICMB Group 5 (optional) Performs ICMB group control operation 

Control according to settings from the Group Control Table 
parameter in the PEF Configuration Parameters. 

Send Alert 6 (mandatory if alerting is supported) Send alerts in 


order based on the selected Alert Policy. 

Alert actions will be deferred until after the power 
down has completed. 

There is an additional prioritization within alerts 
being sent: based on the Alert Policy Table entries 
for the alert. This is described further in Section 
17.11, Alert Policy Table. 

OEM OEM (optional) Priority determined by OEM. 


17.7 Event Filter Table 


The Event Filter Table consists of a set of rows or ‘entries’ that define each filter. The following table specifies 
the fields that comprise a row in the Event Filter Table. These entries include a series of masks that the BMC 
applies to the event data. The fields are designed such that a combination of absolute and ‘wildcarded’ 
comparisons can be used for matching fields in the event record. Thus, either a single event or multiple events can 
match up with a single Event Filter Table entry. 


A PEF implementation is recommended to provide at least 16 entries in the event filter table. A subset of these 
entries should be pre-configured for common system failure events, such as over-temperature, power system 
failure, fan failure events, etc. Remaining entries can be made available for ‘OEM’ or System Management 
Software configured events. Note that individual entries can be tagged as being reserved for system use - so this 
ratio of pre-configured entries to run-time configurable entries can be reallocated if necessary. 


A match occurs when there are event filter table matches (exact or wild-carded) for all compared fields in the 
event message. 


There are two things that can kick off PEF: the arrival of a new event or BMC startup with pending events. 
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Table 17-, Event Filter Table Entry 
Field Description 
Filter Configuration [7]-  1b= enable filter 
Ob= disable filter 
[6:5] - 11b = reserved 
10b = manufacturer pre-configured filter. The filter entry has been 
configured by the system integrator and should not be 
altered by software. Software is allowed to enable or 
disable the filter, however. 
01b = reserved 
00b = software configurable filter. The filter entry is available for 
configuration by system management software. 
[4:0] - reserved 
Event Filter Action All actions are optional for an implementation, with the exception of Alert 
which is mandatory if alerting is supported for one or more channels. 
The BMC will return Ob for unsupported actions. Software can test for 
which actions are supported by writing 1’s to the specified fields and 
reading back the result. (Note that reserved bits must be written with 
0’s) 
reserved 
1b = group control operation (see [ICMB]) 
Ob = no group control operation (see [ICMB]) 
1b = Diagnostic Interrupt (NMI) 
Ob = no Diagnostic Interrupt 
1b = OEM action 
Ob = no OEM 
1b = power cycle 
Ob = no power cycle 
1b = reset 
Ob = no reset 
1b = power off 
Ob = no power off 
1b = Alert 
Ob = no Alert 

Alert Policy Number Used to select an alerting policy set from the Alert Policy Table. The Alert 
Policy Table holds different policies that configure the order in which 
different alert destinations and alerting media are tried. 

[7]- reserved 

[6:4] - group control selector (1-based). Selects entry from group control 
table. (see [ICMB) 

[3:0] - policy number. Value is ‘don’t care’ if Alert is not selected in the 
Event Filter Action. 

Event Severity This field can be used to fill in the Event Severity field in a PET alert. The 
severity values are based on the ‘DMI’ severity values used for the 
generic sensor event/reading type code. In the case that more than one 
event filter match occurs for a given Alert Policy Number, the numerically 
highest severity value will be used. 

00h = unspecified 

01h = Monitor 00 0001 

02h = Information 00 0010 

04h = OK (return to OK condition) 000100 

08h = Non-critical condition 00 1000 a.k.a. ‘warning’ 
10h = Critical condition 01 0000 

20h = Non-recoverable condition 10 0000 


5 Generator ID Byte 1 Slave Address or Software ID from Event Message. 
FFh = match any 
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Generator ID Byte 2 Channel Number / LUN to match. FFh = match any see section 0, 
SEL Record Formats 


Sensor Type Type of sensor. FFh = match any 

Seg [FF = match ary 
10 
11 


Event Trigger (Event/Reading FFh = match any 
Type) 


Event Data 1 Event Offset Mask | This bit field is used to match different values of the least significant 
nibble of the Event Data 1 field. This enables a filter to provide a match 
on multiple event offset values. 

Bit positions 15 through 0 correspond to the offset values Fh - Oh, 
respectively. A 1 in a given bit position will cause a match if the value in 
bits 3:0 of the Event Data 1 hold the corresponding value for the bit 
position. Multiple mask bits can be set to 1, enabling a match to multiple 
values. A match must be made with this field in order to have a match for 
the filter. 

data 1 

7:0 - mask bit positions 7 to 0, respectively. 

data 2 

15:8 - mask bit positions 15 to 8, respectively. 

12 Event Data 1 AND Mask This value is applied to the entire Event Data 1 byte. The field is Used to 
indicate ‘wildcarded’ or ‘compared’ bits. This field must be used in 
conjunction with Compare 2. To match any Event Data field value, just set 
the corresponding AND Mask, Compare 1, and Compare 2 fields to OOh. 
(See Section 17.8, Event Data 1 Event Offset Mask for more information). 
Note that the Event Data 1 AND mask, Compare 1 mask, and Compare 2 
masks will typically be set to wild-card the least significant of Event Data 1 
in order to allow the Event Data 1 Event Mask field to determine matches 
to the event offset. 

Bits 7:0 all have the following definition: 

0 = Wildcard bit. (drops this bit position in the Event Data byte out of 
the comparison process) Corresponding bit position must be a 1 in 
Compare 1, and a 0 in Compare 2. 

(Note - setting a 0 in this bit, a 1 and Compare 1 anda 1 in 
Compare 2 guarantees that you'll never have a match.) 

1 = use bit for further ‘exact’ or 'non-exact comparisons based on 
Compare 1 and Compare 2 values. 

13 Event Data 1 Compare 1 Used to indicate whether each bit position’s comparison is an exact 
comparison or not. (See Section 17.8, Event Data 1 Event Offset Mask for 
more information). Here, ‘test value’ refers to the Event Data value after 
the AND Mask has been applied. 

Bits 7:0 all have the following definition: 

1 = match bit in test value exactly to correspond bit position in 
Compare 2 

0 = contributes to match if corresponding bit in test value matches 
corresponding bit in Compare 2. 

14 Event Data 1 Compare 2 (See Section 17.8, Event Data 1 Event Offset Mask for more information). 
Here, ‘test value’ refers to the Event Data value after the AND Mask has 
been applied. 

Bits 7:0 all have the following definition: 
1 = match a ‘1’ in corresponding bit position in test value. 
0 = match a ‘0’ in corresponding bit position in test value. 


| Event Data 2 AND Mask | 
[EventData2Comparet | S Oe 
| Event Data2Compare2 | S O 
| Event Data 3 AND Mask | 
| Event Data 3 Compare 1 | 
| Event Data 3 Compare | 
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17.8 Event Data 1 Event Offset Mask 


The Event Data 1 Event Offset Mask field in the Event Filter is used to match multiple bits in the Event Offset 
field of the Event Data 1 byte of an event. The least significant nibble of event data | typically holds an event 


offset value. This offset selects among different possible events for a sensor. For example, a ‘button’ sensor 


supports a set of sensor-specific event offsets: 0 for Power Button pressed, 1 for Sleep Button pressed, and 2 for 
Reset Button pressed. When an event is generated, it could have a 0, 1, or 2 in the event offset field depending on 


what button press occurred. 


The Event Offset Mask makes it simple to have a filter match a subset of the possible event offset values. Each bit 
in the mask corresponds to a different offset values starting with bit 0 in the mask corresponding to offset 0. For 


example, if it is desired to have a filter match offsets 0 and 2, but not 1, the mask would be configured to 


000_0000_0000_0101b. 


17.9 Using the Mask and Compare Fields 


The AND Mask and the Compare 1 and Compare 2 fields are used in combination to allow wildcarding, ‘one or 
more bit(s)’, and exact comparisons to be made between bits in the corresponding event data byte. One way to 
understanding the bits is to look at the way they’re used in combination. First the AND Mask is applied to the test 
value. The result, referred to below as the test value, is then bit-wise matched based on the values in the Compare 


1 and Compare 2 fields, as summarized in the following table. 


Table 17-, Comparison-type Selection according to Compare Field bits 


1 2 


1 1 exact compare 
to 1 

exact compare 
to 0 


‘non exact’ 
compare to 1 


‘non exact’ 
compare to 0 


This bit in the test value must be = 1 for a match. 
If it's 0, there is no match. All ‘exact’ comparison bits must match 
the corresponding bits in the test value for a match. 


This bit in the test value must be = 0 for a match. 

If its 1, there is no match. All ‘exact’ comparison bits must match 
the corresponding bits in the test value for a match. 

If this bit in the test value is 1, it contributes to a match. There will 
be a match if any one of the bit positions that has a ‘0’ in 
Compare 1 field has a bit in the test value that matches the 
polarity given in the corresponding bit position in the Compare 2 
field. - unless there are exact comparisons that don’t match. 

If this bit in the test value is 0, it contributes to a match. There will 
be a match if any one of the bit positions that has a ‘0’ in 
Compare 1 field has a bit in the test value that matches the 
polarity given in the corresponding bit position in the Compare 2 
field. - unless there are exact comparisons that don’t match. 


17.10 Mask and Compare Field Examples 


The following examples show how the fields are used. See 
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Appendix B - Example PEF Mask Compare Algorithm for example matching algorithm. 


Example 1: Match (bit 2 = 1) AND (bit 1 = 1), and ignore all other bits. 

AND Mask: 0000 0110 Force all bits except bits 2 and 1 to 0. (Forcing to 0 and comparing exactly to 0 makes 
the other bits ‘don’t care’) 

Compare 1: 1111 1111 Compare all bits exactly. 

Compare 2: 0000 0110 Compare for bits 2 and 1 both = 1, and remaining bits = 0. 

Example 2: Match (bit 2 = 1) OR (bit 1=1), and ignore all other bits. 

AND Mask: 0000 0110 Force all bits except bits 2 and 1 to 0. 

Compare 1: 1111 1001 Compare for at least one of bit 2 or bit 1being polarity specified in the corresponding bit 
position in Compare 2. Compare remaining bits exactly. 

Compare 2: 0000 0110 Compare for bit 2 or bit 1 = 1, and remaining bits = 0 exactly. 

Example 3: Match (bit 2 = 1) AND (bit 1 = 0) 

AND Mask: 0000 0110 Force all bits except bits 2 and 1 to 0 

Compare 1: 1111 1111 Compare all bits (after AND) exactly 

Compare 2: 0000 0100 Compare for bit 2 = 1 and bit 1 = 0, and remaining bits = 0 exactly. 

Example 4: Match bit 2 = 1 OR bit 1 =0 

AND Mask: 0000 0110 Force all bits except bits 2 and 1 to 0. 

Compare 1: 1111 1001 Compare all bits except bits 2 and 1 exactly. 

Compare 2: 0000 0100 Compare for bit 2 = 1 OR bit 1 = 0, and remaining bits = 0 exactly. 

Example 5: Match most significant nibble = 1010 exactly, and any bit in LSN = 1. 

AND Mask: 1111 1111 Look at all bits 

Compare 1: 1111 0000 Compare all bits in MSN exactly. 

Compare 2: 1010 1111 Compare MSN = 1010 exactly, and for a 1 in one or more positions in LSN 

Example 6: match MSN = 1010 exactly, and any bit in LSN = 0. 

AND Mask: 1111 1111 Look at all bits 

Compare 1: 1111 0000 Compare all bits in MSN exactly. 

Compare 2: 1010 0000 Compare MSN = 1010 exactly, and for a 0 in one or more positions in LSN 


17.11 Alert Policy Table 


Platform Event Filtering supports alerting as one of the selectable actions that can occur when an event matches 
an event filter table entry. The alerting media and the different alert destinations that are tried are determined by 
the settings in the Alert Policy Table. 


The Alert Policy Table definition enables implementations to offer multiple policy sets. For example, one policy 
could be configured to generate LAN Alerts and Pages and be associated with critical and non-recoverable events, 
while another may generate only LAN Alerts and be associated with non-critical events. It would even be possible 
to configure a ‘Chassis Security’ event to notify one party, while an ‘Over-temperature’ event could be delivered 
to a different destination. 


The table entry also contains a parameter that can be used to select whether the alert is delivered to all enabled 
destinations, or that different destinations are tried until the alert is successfully delivered. Altering the policy 
table entries can change the whether certain destinations are processed or not. 


A policy number is used to group multiple table entries into a policy set. The collection of entries determines 
which different media and alert types can be tried when an alert action occurs. When a Platform Event Filter table 
entry is configured to perform an alert action on an event, an alert policy number is also configured for the action. 
The BMC takes this policy number and uses it to look up the entries for the corresponding policy set in the Alert 
Policy Table. 


The policy number also determines the priority of alert policies. Only one starting Alert policy will be used for a 
given event. If an event matches more than one alert policy, the policy with the lowest number will be used. 


Implementations that support alerting are required to provide at least one table entry. It is recommended that an 
implementation supports at least one policy table entry for each different channel over which an alert can be 
delivered. 
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Table 17-, Alert Policy Table Entry 


Policy Number / This value identifies the entries belonging to a particular policy set. When an Alert Action is 
Policy taken, the BMC will scan the Alert Policy Table and will attempt to generate alerts based on the 
entries that form the policy set. 


[7:4] - policy number. 1 based. 0000b = reserved. 
[3]- Ob = this entry is disabled. Skip to next entry in policy, if any. 
1b = this entry is enabled. 
[2:0] - policy 
Oh = always send alert to this destination. 
th = if alert to previous destination was successful, do not send alert to this destination. 
Proceed to next entry in this policy set. 
2h = if alert to previous destination was successful, do not send alert to this destination. 
Do not process any more entries in this policy set. 
3h = if alert to previous destination was successful, do not send alert to this destination. 
Proceed to next entry in this policy set that is to a different channel. 
4h = if alert to previous destination was successful, do not send alert to this destination. 
Proceed to next entry in this policy set that is to a different destination type. 
Channel / Destination Channel that the alert is to be sent over. Channel determines which set of destination 
addresses or phone numbers is used. Destination addresses and/or phone numbers are set 
via the LAN and/or serial/modem configuration parameter commands. The Alert Type (e.g. 
PET, TAP, Dial Page, etc.) is specified in the configuration parameters associated with the 
specified destination. 
[7:4] = Channel Number. 
[3:0] = Destination selector. 
Alert String Key This field holds information that is used to look up the Alert String to send for this Alert Policy 
entry. 
00h = no alert string. 
[7] - Event-specific Alert String 
1b = Alert String look-up is event specific. The following Alert String Set / Selector sub- 
field is interpreted as an Alert String Set Number that is used in conjunction with 
the Event Filter Number to lookup the Alert String from the PEF Configuration 
Parameters. 
Ob = Alert String is not event specific. The following Alert String Set / Selector sub-field 
is interpreted as an Alert String Selector that provides a direct pointer to the 
desired Alert String from the PEF Configuration Parameters. 


[6:0] - Alert String Set / Selector. This value identifies one or more Alert Strings in the Alert 
String table. When used as an Alert String Set Number, it is used in conjunction with the 
Event Filter Number to uniquely identify an Alert String. When used as an Alert String 
Selector it directly selects an Alert String from the PEF Configuration Parameters. 


The Alert String Key and lookup mechanism allows the Alert String to be ‘Event Specific’ - 
meaning the string selection is determined by both the Event Policy Entry and Event Filter, or, 
the string can be selected by the Event Policy alone. An Alert String can be pointed to by 
multiple policy entries. 


The Alert Policy Entry identifies a particular channel and destination for an alert. This in turn, 
identifies the alert type. Thus, the binding of an Alert Policy Entry and an Alert String effectively 
provides a mechanism for allowing different Alert Strings to be selected based on the alert 
destination, or the type of alert destination. For example, a single Alert String could be shared 
among all Alert Policy Entries for ‘Dial Page’ destinations, while event-specific Alert Strings 
could be used for alerts to LAN destinations. 


17.12 Alert Testing 


BMC includes an ability to test alert configurations. This is accomplished through the Alert Immediate command. 
This command allows a particular alert destination to be selected and an alert sent to it. Typically, software will 
use the volatile settings in the configuration parameters for the channel to hold alert destination information until 
the setting is verified by the user, at which time it can be moved into one of the non-volatile positions. 
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17.13 Alert Processing 


The BMC starts from the beginning of the Alert Policy Table, scanning for entries that match the event. The BMC 
will scan all entries in the Event Filter table and initiate the highest priority Alert Policy for which there was a 
match. If multiple filters match and have the same alert policy priority, the first matched event filter will be used. 
(Since an Alert String can be associated with an event filter, it may be important to order the event filter table 
such that the more ‘granular’ filters occupy the earlier entries, and the more generic filters occupy the later 
entries.) 


BMC implementations are allowed to have multiple alerts simultaneously in progress on the same channel or 
across multiple channels. 


If an alert was successfully delivered, the BMC will either stop processing the policy, or will continue to process 
alert policy table entries - based on whether the destination was configured to stop alert processing on success or 
not. Each entry in the alert policy is processed in order until all entries have been processed (meaning the alert 
was either sent, failed, or the alert was skipped). 


17.13.1 Alert Processing after Power Loss 


It is possible that more events will come in while an alert is being processed. Each time a SEL Record is 
completely processed for alerts, the BMC saves a copy of the Last BMC Processed Record ID to NV storage. 
(“Completely processed” means that there are no incompletely processed alert policies for the event). That way, 
if AC power is lost the BMC can tell whether there are events that may not have been processed for alerting by 
comparing the Last BMC Processed Record ID with the Record ID of the last SEL Entry. 


It’s possible that alerts were sent to some destinations, but not all, when power was lost. When power comes 
back up, the BMC will start processing the entire record and as a result some alerts may get re-sent. 


17.13.2 Processing non-Alert Actions after Power Loss 


After the BMC powers up, and before restoring the system power state, it uses PEF to check pending events for 
matches that would have yielded a “power off” action. If there is a match, it sets the previous power Restore 
State to Off and leaves the system powered off. The BMC skips processing reset or power cycle actions that 
were pending when AC was lost. 


In order to know how many events to process, the BMC should copy the Record ID or timestamp of the last 
SEL Entry and only process records up to that point as events that were pending when AC was lost. That way, if 
a new event comes in, it will be handled as a new event rather than as an event that was pending when AC was 
lost. 


17.13.3 Alert Processing when IPMI Messaging is in Progress 


All automatically generated alerts are deferred if IPMI Messaging is in progress on the channel. The remote 
console software can direct the BMC to skip processing deferred events by setting the Last BMC Processed 
Record ID value for all filters to the Record ID of the last SEL Record. 


17.13.4 Sending Multiple Alerts On One Call 


To avoid unnecessary phone calls, it is desirable to have multiple alerts be delivered to a given PPP Account 
before hanging up, rather than hanging-up after each event. The serial/modem configuration parameters and the 
Alert Policy entries can be configured to support this. To have this accomplished, the configuration must fit the 
following rules. 


e The Connection Hold Time parameter for the PPP Accounts should be set to a value that covers the time 
that you'd like the call to be maintained waiting for the next event to occur. Since a new alert will restart 
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the connection time time-out, the value should be set to the time required to maintain the connection 
between alerts. 


All event policies should be configured to have alerts to each channel delivered in priority order starting 
with the highest priority destination first. 


17.13.5 Serial/Modem Alert Processing 
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Alerts on the same given serial/modem channel processed according to priority. Alerts to PPP Accounts are 
processed with higher priority than Dial Page or TAP Page alerts. PPP Accounts are prioritized according to the 
account selection, with the lowest account selector corresponding to the highest priority with the lowest account 
selector as summarized in the following table: 


Table 17-, Serial/Modem Alert Destination Priorities 


Priority 
Destination Type (0 = highest) Comments 
PPP Account #1 1 All destinations behind a given PPP Account are at equal 
PPP Account #2 2 priority. Destinations behind an account are handled in 
PPP Account ZN N the order that they occur in the Alert Policy Table entry 
associated with the account. 
Dial Page and TAP Page N+1 All Dial Page and TAP Pages are at equal priority. They 
are handled in the order that they occur in the Alert Policy 
Table entry. 


The following specifies how serial/modem alerts from the same channel are handled: 


The BMC will not prematurely terminate a PPP Alert, Dial Page, or TAP Page in progress to a given 
destination, with the exception that an implementation is allowed to in order to handle a power off, power 
cycle, or system reset transition. In this case, the alert should be resumed once the transition has completed. 


The BMC checks the event filters for matches to the event. If there is more than one alert policy selected by 
the match, the BMC will only execute the highest priority (lowest numbered) alert policy. 


The BMC must keep track of how far it has processed the alert policy associated with the event. It does this 
in case it needs to prematurely terminate a call because of a power off, power cycle, or system reset 
operation. 


The BMC processes each alert policy through to completion. Completion of processing means that all alerts 
were either sent or deferred. 


If there is no presently active connection, a connection will be made for the first alert destination in the 
alert policy sent and the alert sent. 


The PPP Account Connection Hold Time parameter determines how long a PPP call will be held open 
waiting for another alert. The PPP connection will only close when the time expires, or if an alert to a 
higher priority PPP Account occurs. 


The call to a PPP Account will be dropped without waiting for the Connection Hold Time to expire if alerts 
fail to all destinations for a given policy. 


The Connection Hold Time time-out must be restarted whenever a new alert is sent to the account. 


If a PPP account connection is already active and the alert is to a destination behind that PPP account, the 
BMC will wait for any alerts in progress to that account to complete and then send the present alert. 


If the alert is to a destination that is behind a higher priority PPP account, the present connection will be 
terminated as soon as the present alert to that account has completed, regardless of the connection hold 
time. The BMC will then dial the higher priority account and sent the alert. 
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If a PPP account connection is already open it will be used unless the alert is to a lower-priority destination 
type, in which case the alert will be deferred until connection hold time for the present connection expires. 


If a Dial Page or TAP Page is already active, the BMC will wait for the alert in progress to complete and 
then send the present alert, regardless of whether the present alert is of higher priority. (Completion of an 
alert in progress for an unacknowledged alert means that the alert has been sent. For an acknowledged alert, 
completion means the alert has been sent and the acknowledge received or all retries and timeouts have 
concluded and the alert is considered to have failed.) 


The Page Blackout Interval is essentially a ‘throttle’ that prevents pages from being sent ‘back-to-back’. 
See 14.10, Page Blackout Interval. 


17.14 PEF and Alert Handling Example 


The following figure presents a snapshot of event and alert processing using PEF. It also helps illustrate the 
relationship between entries in the serial/modem configuration parameters. 


1. 
2. 


The present event being processed is identified as event with Record ID = “N+2” 


The BMC scans all filter table entries for matches to the present event. When done, it finds three entries with 
Alert actions that have been matched: event filters X, P, and T. 


The BMC handles matched filters in priority order based on the action associated with the filter. The Power 
Off action is higher priority than Alert actions, so filter X is acted on immediately and the power OFF action 
performed. 


There are two matched filters left, both with Alert actions. Filter P is acted on because it has the lower policy 
number. The BMC ‘queues’ information for the alert policy and the event filter so it can be processed later. 


The event triggers Alert Policy #3. The BMC sends the alert to LAN destination #1, and then sends the alert 
to serial/modem destination #1. The figure shows that serial/modem destination #1 is a PPP Alert 
destination, therefore the BMC looks up the corresponding PPP Account information from the serial/modem 
configuration parameters. The PPP account is account #1. This is the highest priority account. If the account 
is not already active, the BMC will terminate any lower priority call in progress and then call the account #1 
and send the alert. 


The completion of the alert policy for event N+2 may cause the Last BMC Processed Record ID to be set to 
N+2 - but it also may not. Whether the Last BMC Processed Record ID is advanced is based on whether all 
deferred alerts have been processed. Due to prioritization, it’s possible that in some cases the alert policy 
triggered for event N+2 could complete while an alert policy associated with an earlier event ‘N’ could still 
have destinations to be processed. 
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Figure 17-, Alert Processing Example 
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17.15 Event Filter, Policy, Destination, and String Relationships 


The following figure illustrates the relationship between the different structures and configuration parameters 
related to platform event filtering and alerting. Note that the number of table entries and support for different alert 
types is implementation dependent. 


The figure shows the lookup process that occurs when an event matches an Event Filter Table entry. In this 
example, the entry triggers an Alert that activates alert policy number 3. The policy table is scanned for the first 
entry with a matching policy number. The first matching entry is for a LAN channel. First, a LAN PET trap to 
xxx.212.123.67, then, if that fails a LAN PET trap to xxx.100.200.1 will be tried. If that fails, the next matching 
policy entry will be tried. 


The next policy is for a serial/modem channel. The first alert on this channel will be a Dial Out PET Alert (a.k.a. 
PPP Alert). The second attempt will be a TAP Page. Note that a short ASCII Alert String “System FRED 
Intrusion” is selected by the Alert Policy Entry for the TAP page. The third attempt will be a dial page. Since a 
dial-page is restricted to submitting ‘key pad’ digits via the modem command set, we see that the final attempt is 
used to deliver a numeric page with the number of the system in trouble, and a user-defined ‘911’ to indicate that 
there’s a serious condition. 


In order to simplify the figure, certain parameters associated with the Alert destinations have been left out. For 
example, there are destination phone numbers and modem init strings associated with the paging destinations, and 
MAC address and Gateway Address values associated with the LAN Alert destinations. 
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Figure 17-, Event Filter, Alert Policy, and Alert Destination, & String Relationships 
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Alert String 3 is an example of an event-specific Alert String. = = F 
Note that bit 7 is set in the Alert String Key field from the Alert Policy Table. KA OK 
The value '2' in the Event Filter field matches up with Event Filter Number 2, which 

in this example is a filter that matches up to Chassis Intrusion events. 


17.16 Populating a PET 


The following table outlines the way PET fields are populated for an IPMI alert. See [PET] for more information. 
The Community String portion of the PET can be obtained from the configuration parameters associated with 
the channel from which the trap is issued. If the Community String parameter is not supported, the string ‘public’ 
should be sent. 


The following table lists the population of the PET Specific Trap fields for an IPMI alert: 
Table 17-, PET Specific Trap Fields 


PET Field IPMI Source 
Event Sensor Type Sensor Type code from event message 
Event Type Event/Reading Type code from event message 
Event Offset [7] = Event Dir bit from event message 
[3:0] = Event Offset for Event Data 1 byte of event message 
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The following table lists the IPMI source and formatting for fields that go into the ‘variable bindings’ fields of a 


PET. 
Table 17- - PET Variable Bindings Field 
size/ 
PET Field type IPMI Source 
GUID Recommended that BMC populate this with the System GUID. If a system GUID 
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Sequence # / 
Cookie 
Local Timestamp 


UTC Offset 


Trap Source 
Type 


Event Source 
Type 


Event Severity 


Sensor Device 


Sensor Number 
Entity 


Entity Instance 


Event Data 


Language Code 


bytes 
word 


dword 


= = 
E å 
å 


o 
= 
D 


byte 


yt 


oO 


ojo 

< 
> 
oO 


byte 


octet 
string 


(8) 


byte 


is not available, a device GUID for the BMC may be substituted. 

BMC should increment the value in this field for each new PET issued, but leave 
the value unchanged for PET retries. 

BMC should populate this field with the time value that would be used to log the 
event in the SEL. Per PET, this needs to be converted to represent number of 
seconds from 0:00 1/1/98. 

0000 0000 = unspecified. 

Optional. UTC Offset in minutes (two’s complement, signed. -720 to +720, 
OxFFFF=unspecified) 

Class of the device or software that originated the trap on the network. Use 20h 
for PETs that are issued from the BMC. 


Use 20h for events that are automatically generated by the BMC (e.g. by PEF) 

It is recommended that 21h be used for IPMI-format PETs that are generated by 
system software instead of automatically by the BMG. 

Severity (based on DMI Event Severity). 

If PEF specifies an event severity for the event filter that triggered the Alert, that 
severity should be used instead. 

0x00 = unspecified 


0x01 = Monitor 00_0001b 
0x02 = Information 00_0010b 
0x04 = OK (return to OK condition) 00_0100b 
0x08 = Non-critical condition 00_1000b a.k.a. ‘warning’ 
0x10 = Critical condition 01 0000b 
0x20 = Non-recoverable condition 10 0000b 


In IPMI this holds an ID (IC address or SWID) of the controller or software 

entity that generated the event. This comes from the event message. Le if the 

BMC received the event from controller C2h, this value would be set to C2h, not 

to the BMC's address. 

Sensor number from the event message. 

Entity ID from IPMI v1.5specification. (Optional). An implementation can elect to 

look up the Entity ID associated with the sensor and send that information in the 

PET. 

00h = unspecified 

This field can hold is the Entity Instance value associated with the preceding 

Entity field. 

00h = unspecified 

Additional parametric data byte - formatted as specified by Event Type in 

combination with Event Source. Interpreted as individual octet fields. 

Event Data 1 - Populate this field with the Event Data 1 byte from the Event 
Message 

Event Data 2 - Populate this field with the Event Data 2 byte from the Event 
Message 

Event Data 3 - Populate this field with the Event Data 3 byte from the Event 
Message 

Event Data 4:8 - These bytes are not used with IPMI messages. They should be 
set to 00h. Software should ignore their content. 

Per IPMI v1.0 FRU Information Format. FFh = ‘unspecified’. This field can be 

used in conjunction with the OEM fields, below, to indicate the language that 

any strings are in. Note that language is different than character set. Character 

sets are specified as ASCII or UNICODE, per type/length bytes. 
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size/ 
PET Field type 
Manufacturer ID 
System ID 
OEM Custom octet 
Fields string 
(max. 
64) 


IPMI Source 

Manufacturer ID using Private Enterprise IDs per IANA. This should reflect the 
ID of the manufacturer of the System from which the alert it being issued. 
Specified by manufacturer given by Manufacturer ID field, this number can be 
used to identify the particular system/product model or type. 

One or more fields given in IPMI v1.0 FRU Information field format: 
Type/length code byte followed by N data bytes for each field. 

Fields end when type/length byte indicates ‘no more records’ (C1h). A Cth in 
octet 47 indicates no OEM Custom Fields. 


17.16.1 OEM Custom Fields and Text Alert Strings for IPMI v1.5 PET 


An IPMI format PET (PET Event Source = 20h or 21h) provides additional specification on the use of the 
Type/Length Byte in the OEM Custom Fields by defining additional special values as follows: 


PET OEM Field Type/Length Byte special values 


00h > reserved 
40h > reserved 


80h > typed field (‘PET multirecord’ field) 


COh > empty field 
Clh > end of fields 


With this encoding, a Type/Length value of 80h indicates the start of a ‘PET multirecord’ field where the field 
format is as follows. This format enables the PET trap to carry an Alert String from PEF, while allowing OEM 
data to coexist in the custom fields as well. 


Table 17-, IPMI PET Multirecord Field Format 


byte | Field 
1 Type/Length 


Definition 
80h (PET multirecord field) 


2 Encoding/Length 


7:6 Record Encoding 
00b = binary / unspecified 
01b= ASCII 
10b = UNICODE 
11b = reserved 
5:0 Record Data Length in bytes (number of bytes in Record Data field) 


3 Record Type 


7:4 reserved 
3:0 Record Type 
Oh = reserved 
1h= Text Alert String 
2h = OEM Data per OEM Identified by IANA in first three bytes of 
Record Data 
3h = OEM Data per OEM Identified by Manufacturer ID field 


4:N Record Data 


Data per Record Type 


17.17 PEF Performance Target 


Excluding PEF Action Delays, a PEF action should nominally occur within two seconds of the corresponding 
Event Message being received by the BMC. For events generated internal to the BMC, this should occur within 
two seconds of the event being written to the SEL or delivered to the Event Message Buffer. Note that this does 
not include delays for event detection and formatting the event record, nor the time to poll and accumulate the 
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data that triggers the event. For example, it may take the BMC several seconds to detect a fan failure, that time is 
not included in this performance target. 


For alerts, this target also represents the time to initiate the processing of an alert policy. The actual time it takes 
to complete an alert policy is widely variable, dependent on factors such as whether the alert is deferred, plus 
elements such as telephone system and network response delays, thus a performance target is not specified for 
alert completion at this time. 
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18. Firmware Firewall & Command Discovery 


IPMI v1.5 and earlier specifications allow almost any supported IPMI operation to be accomplished from the 
system interface. This includes writing SDRs, configuring alerts, setting thresholds, sending messages to other 
media, and other actions that could be used to ‘spoof? a non-existent system failure. In a standalone system, this is 
normally an acceptable risk since errant local software would typically only affect the system it was running on. 


Some blade chassis implementations have a central management module (CMM) that aggregates and acts on 
information from BMCs that reside on individul compute blades. In this environment, a malicious piece of 
software could potentially spoof a hazardous voltage or thermal condition that causes the CMM to shutdown the 
entire chassis. Or, if a shared management bus is used, software running on one blade could potentially send IPMI 
messages that could shut down, reset, or reconfigure management on other blades. 


However, it takes more than just blocking those types of commands or operations. The IPMI specifications 
needed to provide a way to tell software that commands that would otherwise be mandatory have been intentionlly 
made unavailable for protection purposes and are not unavailable because of an error. 


Configuration of Firmware Firewall capabilities is supported by commands that allow software to enable/disable 
individual commands and command sub-functions, and to discover which particular commands and command 
sub-functions can be configured on a given implementation. These ‘command support discovery’ commands can 
implemented without requiring the enable/disable commands of Firmware Firewall in order to provide a common 
mechanism for discovering which IPMI commands and functions a given management controller supports. 


Firmware Firewall capabilities can be extended to include interfaces (channels) other than the system interface, 
such as the IPMB. This can be used to prevent add-in cards or other parties from performing certain IPMI 
functions. 


The Firmware Firewall capability does not affect the operation of user and channel privileges. That is, if a 
command requires Admin privilege level to be executed, it will still require Admin privilege if enabled by 
Firmware Firewall. 


The Firmware Firewall and command discovery commands include the following: 


1. Commands for the general discovery of supported commands and sub-functions on a given interface - 
a.k.a. “command discovery commands”: 


Command Section 
Get NetFn Support 21.2 
Get Command Support 21.3 
Get Command Sub-function Support 21.4 


2. Commands to discovery what commands and functions can be enabled/disabled - a.k.a. “configurable 
command discovery” commands: 


Command Section 
Get Configurable Commands 215 
Get Configurable Command Sub-functions 21.6 


3. Commands that are used to enable/disable any configurable commands or sub-functions: 


Command Section 
Set Command Enables 21:7 
Get Command Enables 0 
Set Command Sub-function Enables 21:3 
Get Command Sub-function Enables 21.10 
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19. Command Specification Information 


This section provides specifications for elements that apply to all requests and responses presented later in this 
document. 


19.1 Specification of Completion Codes 


Completion codes are specified in Section 5.2, Completion Codes. Additional command-specific completion 
codes, if any are listed in the “completion code’ field description for the command. In some cases, use of certain 
command-specific completion codes is mandatory. This will be listed alongside the description of the completion 
code in the command table. If no command-specific completion codes are listed, the description will solely 
indicate that the field is the ‘completion code’ field. Note that the generic completion code values can be used 
with any command, regardless of whether additional command-specific completion codes are defined. Therefore 
generic completion codes are not explicitly listed in the command tables. Refer to Section 5.2 for additional 
requirements and guidelines. 


19.2 Handling ‘Reserved’ Bits and Fields 


Unless otherwise noted, Reserved bits and fields in commands (request messages) and responses shall be written 
as ‘0’. Applications must ignore the state of reserved bits when they are read. 


19.3 Logical Unit Numbers (LUNs) for Commands 


Unless otherwise specified, commands that are listed as mandatory must be accessed via LUN 00b. An 
implementation may elect to make any command available on any LUN or channel as long as it does not conflict 
with other requirements in this specification. 


19.4 Command Table Notation 


The following section includes command tables that list the data that is included in a request or a response for 
each command. The completion code for a response is included as the first byte of the response data field for each 
command. The Network Function (NetFn) and command byte values for each command are specified in separate 
tables. 


The following notation is used in the command tables. 


Request Data Identifies portion of the table that lists the fields that are included in the data portion of a 
request message for the given command. 


Response Data Identifies portion of the table that lists the fields that are included in the data portion of a 
response message for the given command. Note that the completion code is always listed as the 
first byte in the response data field. 


- Empty Field. A dash (-) in the byte column indicates that there is no request data for the 
command. 


4 Single Byte Field. A single value in the byte column of a command table is used to identify a 
single byte field. The value represents the offset to the field within the data portion of the 
message. In some cases a single byte field with follow a variable length field (see following), 
in which case the single byte offset will be represented with an alphabetic variable and number 
representing the single byte field’s location relative to the end of the variable length field. E.g. 
N+1. 
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5:7 


(3) 
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Multi-byte Field. Indicates a multi-byte field. The byte column indicates the byte offset(s) for 
a given field. For a multi-byte field, the first value indicates the starting offset, the second 
value (following the colon) indicates the offset for the last byte in the field. For example, 5:7 
indicates a three-byte field spanning byte offsets 5, 6, and 7. 


In some cases, multi-byte fields may be variable length, in which case an alphabetic variable 
will be used to represent the ending offset, e.g. 5:N. Similarly, a field may following a variable 
length field. In this case the starting value will be shown as an offset relative to the notation 
used for the previous field, e.g. if the previous field were 5:N, the next field would be shown 
starting at N+1. 


Lastly, a variable length field may follow a variable length field, in which case a relative 
starting offset will be shown with an alphabetic value indicating a relative ending offset, e.g. 
N+1:M. 


Optional Fields. When used in the byte column of the command tables, parentheses are used 
to indicate optional data byte fields. These can be absent or present at the choice of the party 
generating the request or response message. Devices receiving the message are required to 
accept any legal combination of optional data byte fields. 


Unless otherwise indicated, if an optional byte field is present all prior specified byte fields 
must also be present. Similarly, if an optional byte field is absent all following byte fields must 
also be absent. For example, suppose a request accepts 4 data bytes. If data byte 3 was shown 
in parentheses as ‘(3), it would indicate that byte 3 and following were optional. A legal 
request could consist of just bytes [1 and 2], bytes [1, 2, and 3,] or bytes [1, 2, 3 and 4]. It is to 
eliminate just byte 3, but include byte 4. Le a request with data bytes [1, 2, and 4], would be 
illegal. 


Multi-byte fields that are shown as optional cannot be split. Either all bytes for the field are 
present or absent. Le. if a four byte multi-byte field is listed as optional, it is illegal to include 
the first two bytes, but not the second two bytes. 
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20. IPM Device “Global” Commands 


This section presents the commands that are common to all Intelligent Platform Management (IPM) devices that 
follow this specification’s message/command interface. This includes management controllers that connect to the 
system via a compatible message interface, as well as ‘IPMB Devices’. 


IPMI Management Controllers shall recognize and respond to these commands via LUN 0. Refer to Appendix G - 
Command Assignments 


for the specification of the Network Function and Command (CMD) values and privilege levels for these 
commands. O/M = Optional/Mandatory. 


Table 20-, IPM Device ‘Global’ Commands 


[Command -—-— Section | om | 
Wan Rest 23 | or] 


[Manufacturing Teston— [208 [ OG 
[Set ACPI Power State == [26 | OG 
[GeiDevæeGUD 208 |o] 


Broadcast Commands 


Broadcast ‘Get Device ID’ 


[1] This command is not required to return a response in all implementations. 

[2] Broadcast is over IPMB channels only. Request is formatted as an entire IPMB 
application request message, from the RsSA field through the second checksum, 
with the message prefixed with the broadcast slave address, 00h. Response 
format is same as the regular ‘Get Device ID’ response. 

[3] Mandatory if Set ACPI Power State command is implemented on given 
management controller. 


20.1 Get Device ID Command 


This command is used to retrieve the Intelligent Device’s Hardware Revision, Firmware/Software Revision, and 
Sensor and Event Interface Command specification revision information. The command also returns information 
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regarding the additional ‘logical device’ functionality (beyond ‘Application’ and ‘IPM’ device functionality) that 
is provided within the intelligent device, if any. 


While broad dependence on OEM-specific functionality is discouraged, two fields in the response allow software 
to identify controllers for the purpose of recognizing controller specific functionality. These are the Device ID and 
the Product ID fields. A controller that just implements standard IPMI commands can set these fields to 
‘unspecified’. 


Table 20-, Get Device ID Command 
byte data field 


Request Data | | 
Response Data Completion Code 
Device ID. 00h = unspecified. 
3 


Device Revision 

[7] 1 = device provides Device SDRs 

0 = device does not provide Device SDRs 
[6:4] reserved. Return as 0. 

[3:0] Device Revision, binary encoded. 


4 Firmware Revision 1 
[7] Device available: 0=normal operation, 1= device firmware, SDR 
Repository update or self-initialization in progress. [Firmware / SDR 
Repository updates can be differentiated by issuing a Get SDR 


command and checking the completion code.] 
[6:0] Major Firmware Revision, binary encoded. 


Firmware Revision 2: Minor Firmware Revision. BCD encoded. 


IPMI Version. Holds IPMI Command Specification Version. BCD encoded. 
00h = reserved. Bits 7:4 hold the Least Significant digit of the revision, while 
bits 3:0 hold the Most Significant bits. E.g. a value of 51h indicates revision 
1.5 functionality. 02h for implementations that provide IPMI v2.0 capabilities 
per this specification. 

Additional Device Support (formerly called IPM Device Support). Lists the 
IPMI ‘logical device’ commands and functions that the controller supports that 
are in addition to the mandatory IPM and Application commands. 

[7] Chassis Device (device functions as chassis device per ICMB spec.) 
[6] Bridge (device responds to Bridge NetFn commands) 

[5] IPMB Event Generator (device generates event messages [platform 
event request messages] onto the IPMB) 

[4] IPMB Event Receiver (device accepts event messages [platform event 
request messages] from the IPMB) 

[3] FRU Inventory Device 

[2] SEL Device 

[1] SDR Repository Device 

[0] Sensor Device 

Manufacturer ID, LS Byte first. The manufacturer ID is a 20-bit value that is 
derived from the IANA ‘Private Enterprise’ ID (see below). 

Most significant four bits = reserved (0000b). 

000000h = unspecified. OFFFFFh = reserved. This value is binary encoded. 
E.g. the ID for the IPMI forum is 7154 decimal, which is 1BF2h, which would 
be stored in this record as F2h, 1Bh, 00h for bytes 8 through 10, respectively. 
Product ID, LS Byte first. This field can be used to provide a number that 
identifies a particular system, module, add-in card, or board set. The number 
is specified according to the manufacturer given by Manufacturer ID (see 
below). 

0000h = unspecified. FFFFh = reserved. 

Auxiliary Firmware Revision Information. This field is optional. If present, it 
holds additional information about the firmware revision, such as boot block or 
internal data structure version numbers. The meanings of the numbers are 
specific to the vendor identified by Manufacturer ID (see below). When the 
vendor-specific definition is not known, generic utilities should display each 
byte as 2-digit hexadecimal numbers, with byte 13 displayed first as the most- 
significant byte. 


The following presents additional specifications and descriptions for the Device ID response fields: 
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Device ID/Device Instance This number is specified by the manufacturer identified by the Manufacturer ID 


Device Revision 


Firmware Revision 1 


Firmware Revision 2 


IPMI Version 


field. The Device ID field allows controller-specific software to identify the 
unique application command, OEM fields, and functionality that are provided by 
the controller. 


Controllers that have different application commands, or different definitions of 
OEM fields, are expected to have different Device ID values. Controllers that 
implement identical sets of applications commands can have the same Device 
ID in a given system. Thus, a ‘standardized’ controller could be produced where 
multiple instances of the controller are used in a system, and all have the same 
Device ID value. [The controllers would still be differentiable by their address, 
location, and associated information for the controllers in the Sensor Data 
Records. | 


The Device ID is typically used in combination with the Product ID field such 
that the Device IDs for different controllers are unique under a given Product 
ID. A controller can optionally use the Device ID as an ‘instance’ identifier if 
more than one controller of that kind is used in the system. Though 
implementing a Device GUID is the preferred method for uniquely identifying 
controllers. (See section 20.8, Get Device GUID) This field is binary encoded. 


The least significant nibble of the Device Revision field is used to identify when 
significant hardware changes have been made to the implementation of the 
management controller that cannot be covered with a single firmware release. 
That is, this field would be used to identify two builds off the same code 
firmware base, but for different board fab levels. For example, device revision 
"1" might be required for 'fab X and earlier' boards, while device revision "2" 
would be for fab Y and later’ boards. This field is binary encoded and unsigned. 


Major Revision. 7-bits. This field holds the major revision of the firmware. This 
field shall be incremented on major changes or extensions of the functionality of 
the firmware - such as additions, deletions, or modifications of the command set. 
This field is binary encoded and unsigned. 


The Device Available bit is used to indicate whether normal command set 
operation is available from the device, or it is operating in a state where only a 
subset of the normal commands are available. This will typically be because the 
device is in a firmware update state. It may also indicate that full command 
functionality is not available because the device is in its initialization phase or 
an SDR update is in progress. 


Note that the revision information obtained when the Device Available bit is ‘1’ 
shall be indicative of the code version that is in effect. Thus, the version 
information may vary with the Device Available bit state. 


Minor Revision. This field holds the minor revision of the firmware. This field 
will increment for minor changes such as bug fixes. This field is BCD encoded. 


This field holds the version of the IPMI specification that the controller is 
compatible with. This indicates conformance with this document, including 
event message formats and mandatory command support. This field is BCD 
encoded with bits 7:4 holding the Least Significant digit of the revision and bits 
3:0 holding the Most Significant bits. 


The value shall be 02h for implementations that provide IPMI v2.0 capabilities 
per this specification. 
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Additional Device 
Support 


Manufacturer ID 


Product ID 


Auxiliary Firmware 
Revision Information 


This field indicates the logical device support that the device provides in addition 
to the IPM and Application logical devices. 


This field uses the Internet Assigned Numbers Authority (http://www.iana.org/) 
SMI Network Management Private Enterprise Codes a.k.a. “Enterprise 
Numbers” for identifying the manufacturer responsible for the specification of 
functionality of the vendor (OEM) -specific commands, codes, and interfaces 
used in the controller. 


For example, an event in the SEL could have OEM values in the event record. 
An application that parses the SEL could extract the controller address from the 
event record contents and use it to send the ‘Get Device ID’ command and 
retrieve the Manufacturer ID. A manufacturer-specific application could then do 
further interpretation based on a-priori knowledge of the OEM field, while a 
generic cross-platform application would typically just use the ID to present the 
manufacturer’s name alongside uninterpreted OEM event values. 


The manufacturer that defines the functionality is not necessarily the 
manufacturer that created the physical microcontroller. For example, Vendor A 
may create the controller, but it gets loaded with Vendor B’s firmware. The 
Manufacturer ID would be for Vendor B, since they’re the party that defined the 
controller’s functionality. 


The Manufacturer ID value from the Get Device ID command does not override 
Manufacturer or OEM ID fields that are explicitly defined as part of a command 
or record format. 


If no vendor-specific functionality is defined, it is recommended that the field 
can either be loaded with the Manufacturer ID of the party that is responsible for 
the firmware for the controller, or the value FFFFh to indicate ‘unspecified’. 
This field is binary encoded, and unsigned. 


This value can be used in combination with the Manufacturer ID and Device ID 
values to identify the product-specific element of the controller-specific 
functionality. This number is specified by the manufacturer identified by the 
Manufacturer ID field. 


Typically, a controller-specific application would use the Product ID to identify 
the type of board, module, or system that the controller is used in, instead of 
using the data from the FRU information associated with the controller. 


This field is optional. If present, it holds additional information about the firmware 
revision, such as boot block or internal data structure version numbers. The 
meanings of the numbers are specific to the vendor identified by Manufacturer ID 
(above). When the vendor-specific definition is not known, generic utilities should 
display each byte as 2-digit hexadecimal numbers, with byte 13 displayed first as 
the most-significant byte. 


20.2 Cold Reset Command 


This command directs the Responder to perform a ‘Cold Reset’ of itself. This causes default setting of interrupt 
enables, event message generation, sensor scanning, threshold values, and other ‘power up default’ state to be 
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restored. That is, the device reinitializes its event, communication, and sensor functions. If the device incorporates 
a Self Test, the Self Test will also run at this time. 


Table 20-, Cold Reset Command 
byte data field 


Request Data | - | 
Response Data Completion Code 


Note: The Cold Reset command is provided for platform development, test, and platform- 
specific initialization and recovery actions. The system actions of the Cold Reset command 
are platform specific. Issuing a Cold Reset command could have adverse effects on system 
operation, particularly if issued during run-time. Therefore, the Cold Reset command should 
not be used unless all the side-effects for the given platform are known. 


It is recognized that there are conditions where a given controller may not be able to return 
a response to a Cold Reset Request message. Therefore, though recommended, the 
implementation is not required to return a response to the Cold Reset command. 
Applications should not rely on receiving a response as verification of the completion of a 
Cold Reset command. 


20.3 Warm Reset Command 


This command directs the Responder to perform a ‘Warm Reset’ of itself. Communications interfaces shall be 
reset, but current configurations of interrupt enables, thresholds, etc. will be left alone. A warm reset does not 
initiate the Self Test. The intent of the Warm Reset command is to provide a mechanism for cleaning up the 
internal state of the device and its communication interfaces. A Warm Reset will reset communication state 
information such as sequence number and retry tracking, but shall not reset interface configuration information 
such as addresses, enables, etc. An application may try a Warm Reset if it determines a non-responsive 
communication interface - but it must also be capable of handling the side effects. 


Table 20-, Warm Reset Command 
byte data field 


Request Data | - fe 
Response Data Completion Code 
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20.4 Get Self Test Results Command 


This command directs the device to return its Self Test results, if any. A device implementing a Self Test will 
normally run that test on device power up as well as after Cold Reset commands. A device is allowed to update 
this field during operation if it has tests that run while the device is operating. Devices that do not implement a 
self test shall always return a 56h for this command. 


While the Self Test only runs at particular times, the Get Self Test Results command can be issued any time the 
device is in a ‘ready for commands’ state. 


Table 20-, Get Self Test Results Command 
byte data field 


Request Data [Fr S 
Response Data Za Completion Code 


No error. All Self Tests Passed. 
Self Test function not implemented in this controller. 
Corrupted or inaccessible data or devices 
Fatal hardware error (system should consider BMC 
inoperative). This will indicate that the controller 
hardware (including associated devices such as sensor 
hardware or RAM) may need to be repaired or 
replaced. 
reserved. 

all other: Device-specific ‘internal’ failure. Refer to the particular 
device’s specification for definition. 

For byte 2 = 55h, 56h, FFh: OOh 

For byte 2 = 58h, all other: Device-specific 

For byte 2 = 57h: self-test error bitfield. Note: returning 57h does not 

imply that all tests were run, just that a given test has failed. Le 1b 

means ‘failed’, Ob means ‘unknown’. 

[7] 1b = Cannot access SEL device 

[6] 1b = Cannot access SDR Repository 

[5] 1b = Cannot access BMC FRU device 

[4] 1b = IPMB signal lines do not respond 

[3] 1b = SDR Repository empty 

[2] 1b = Internal Use Area of BMC FRU corrupted 

[1] 1b = controller update ‘boot block’ firmware corrupted 

[0] 1b = controller operational firmware corrupted 


20.5 Manufacturing Test On Command 


If the device supports a ‘manufacturing test mode’, this command is reserved to turn that mode on. The 
specification of the functionality of this command is device dependent. A Cold Reset command shall, if accepted, 
take the device out of ‘manufacturing test mode’ - as shall a physical reset of the device. Device-specific 
commands to exit manufacturing test mode are also allowed. 


Note that it may be possible to ‘lock out’ the command interface while in manufacturing test mode, in which case 
the Cold Reset command or other mechanism for exiting manufacturing test mode may fail and a physical reset of 
the device will be necessary to restore the device to normal operation. 


The request parameters for this command are device specific. Typically, the parameters will be used for 
transmitting a password or key that prevents manufacturing test mode from being entered unless the correct values 
are provided. 
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Table 20-, Manufacturing Test On 
byte data field 


Request Data device specific parameters. See text. 
Response Data Completion Code 


20.6 Set ACPI Power State Command 


This command is provided to allow system software to tell a controller the present ACPI power state of the 
system. The Set ACPI Power State command can also be used as a mechanism for setting elements of the platform 
management subsystem to a particular power state. This is an independent setting that may not necessarily match 
the actual power state of the system. This command is used to enable the reporting of the power state, it does not 
control or change the power state. 


There is corresponding information in sensor data record for the controller that tells system software which 
controllers require this notification. The BMC does not automatically inform controllers of changes in the system 
power state. 


Since system management software does not run when the system is in a sleep state, the impact of sleep state on 
the platform management subsystem is mainly one of changes in the automatic handling of sensor scanning and 
events. For example, the system may shut down fans when in a particular power state. If the fans were monitored, 
shutting down the fans without notifying the platform management subsystem could cause a false failure event to 
be generated. Here are two possible ways to handle this: 


a. Have the management controller perform the fan shut down operation after receiving the Set ACPI 
Power State command. In this case, the controller needs an SDR entry indicating that the controller needs 
to receive notification via the Set ACPI Power State command. 


b. Have the controller monitor the system power state by proprietary means, such as a signal line directly 
from the power control hardware to the management controller. The management controller uses the 
signal to directly control the fans without receiving an Set ACPI Power State command. Note that that 
controller should still report the power state using the Set ACPI Power State command. This is to aid out- 
of-band applications that may directly access the controller to get sensor information. 


Out-of-band applications should be prepared to find sensors or controllers that may have become disabled because 
of a sleep state. Ideally, all management controllers should remain enabled while the system is in a sleep state so 
that the sleep state information can be retrieved. Information in the SDR can be used to determine whether a 
controller gets disabled in a particular sleep state. A system will normally power up to a Legacy On state prior to 
the initialization of ACPI, at which time the system power state is known to be ACPI SO/GO. 
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Request Data 


Response Data 


Table 20-, Set ACPI Power State Command 


byte 


data field 
ACPI System Power State to set 
Power states are mutually exclusive. Only one state can be set at a 
time. 
[7] - 1b = set system power state 
Ob = don’t change system power state 
[6:0] - System Power State enumeration 
00h set SO/GO working 
Oih set Gi hardware context maintained, typically equates 
to processor/chip set clocks stopped 
02h set S2 typically equates to stopped clocks with 
processor/cache context lost 
03h set S3 typically equates to “suspend-to-RAM” 
04h set S4 typically equates to “suspend-to-disk” 
05h set 55 /G2 soft off 
06h set S4/S5 sent when message source cannot differentiate 
between S4 and S5 
O7h set G3 mechanical off 
08h sleeping sleeping - cannot differentiate between S1-S3. 
09h Gi sleeping sleeping - cannot differentiate between S1-S4 
OAh setoverride S5 entered by override 
20h set Legacy On Legacy On (indicates On for system that don't 
support ACPI or have ACPI capabilities 
disabled) 


21h set Legacy Off Legacy Soft-Off 
2Ah set unknown system power state unknown 
7Fh no change Use this value when communicating a change 
the device power state without indicating a 
change to the system power state. 
ACPI Device Power State to set 


Power states are mutually exclusive. Only one state can be set at a 
time. 
[7] - 1 = set device power state 
0 = don't change device power state 
[6:0] - Device Power State enumeration 
00h set DO 
Oih set Di 
02h set D2 
03h set D3 
2Ah set unknown 
7Fh no changeUse this value when communicating a change the 
system power state without indicating a change to the device 
power state. 
Completion Code 
The BMC is allowed to return an error completion code if an attempt is 
made to set states it knows the system doesn’t support. 
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20.7 Get ACPI Power State Command 


The command can also be used to retrieve the present power state information that has been set into the 
controller. This is an independent setting from the system power state that may not necessarily match the actual 
power state of the system. Unspecified bits and codes are reserved and shall be returned as 0. 


Table 20-, Get ACPI Power State Command 
byte data field 


Request Data 


Response Data Completion Code 


ACPI System Power State 
[7] - reserved 
[6:0] - System Power State enumeration 


00h 
Oth 


02h 


04h 
05h 
06h 
07h 
08h 
09h 
OAh 


50 / GO 
S1 


sleeping 

G1 sleeping 
override 
Legacy On 


Legacy Off 
unknown 


working 

hardware context maintained, typically equates to 
processor/chip set clocks stopped 

typically equates to stopped clocks with 
processor/cache context lost 

typically equates to “suspend-to-RAM” 

typically equates to “suspend-to-disk” 

soft off 

soft off, cannot differentiate between S4 and S5 
mechanical off 

sleeping - cannot differentiate between S1-S3. 
sleeping - cannot differentiate between S1-S4 
S5 entered by override 

Legacy On (indicates On for system that don't 
support ACPI or have ACPI capabilities disabled) 
Legacy Soft-Off 

power state has not been initialized, or device 
lost track of power state. 


ACPI Device Power State 


[7] 

[6:0] 
00h 
Oth 
02h 
03h 
2Ah 


20.8 Get Device GUID Command 


reserved 
Device Power State enumeration 


unknown - power state has not been initialized, or device lost 


track of power state. 


This command returns a GUID (Globally Unique ID), also referred to as a UUID (Universally Unique IDentifier), 
for the management controller. The format of the ID follows the octet format specified in [RFC4122]. [RFC4122] 
specifies four different versions of UUID formats and generation algorithms suitable for use for a Device GUID in 
IPMI. These are version 1 (0001b) “time based”, and three "name based" versions: version 3 (0011b) *MD5 
hash”, version 4 (0100b) “Pseudo-random”, and version 5 *SHA1 hash”. The version I format is recommended. 
However, versions 3, 4, or 5 formats are also allowed. A Device GUID should never change over the lifetime of 


the device. 
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Table 20-, Get Device GUID Command 


Requestoata [TI o S 
Response Data Completion Code 
GUID bytes 1 through 16. 


Note that the individual fields within the GUID are stored least-significant byte first, and in the order illustrated 
in the following table. This is the reverse of convention described in [RFC4122] where GUID bytes are 
transmitted in “network order’ (most-significant byte first) starting with the time low field. 


Table 20-, GUID Format 


GUID byte | Field MSbyte 
1 node 
2 node 
3 node 
4 node 
5 node 
6 node MSbyte 
7 clock seq and reserved 
8 clock seq and reserved MSbyte 
9 time high and version 
10 time high and version MSbyte 
11 time mid 
12 time mid MSbyte 
13 time low 
14 time low 
15 time low 
16 time low MSbyte 


20.9 Broadcast ‘Get Device ID’ 


This is a broadcast version of the “Get Device ID’ command that is provided for the ‘discovery’ of Intelligent 
Devices on the IPMB. It is only specified for use on the IPMB. Discovery of management controllers on a PCI 
Management Bus is handled via the SMBus 2.0 ‘ARP’ protocol. See [SMBUS] for more information. 


The Broadcast ‘Get Device ID’ command is not bridged but can be delivered to the IPMB using Master Write- 
Read commands. 


To perform a ‘discovery’ the command is repeatedly broadcast with a different rsSA ‘slave address parameter’ 
field specified in the command. The device that has the matching physical slave address information shall respond 
with the same data it would return from a ‘regular’ (non-broadcast) ‘Get Device ID’ command. Since an IPMB 
response message carries the Responder’s Slave Address, the response to the broadcast provides a positive 
confirmation that an Intelligent Device exists at the slave address given by the rsSA field in the request. 


An application driving discovery then cycles through the possible range of IPMB Device slave addresses to find 
the population of intelligent devices on the IPMB. Refer to [ADDR] for information on which slave address 
ranges are allocated for different uses on IPMB. 


Refer to the description of the Get Device ID command, above, for information on the fields returned by the 
Broadcast Get Device ID command response. The IPMB message format for the Broadcast Get Device ID request 
exactly matches that for the Get Device ID command, with the exception that the IPMB message is prefixed with 
the 00h broadcast address. The following illustrates the format of the IPMB Broadcast Get Device ID request 
message: 
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Figure 20-, Broadcast Get Device ID Request Message 


Broadcast | rsSA | netFn/rsLUN check1 rqSA | rqSeq/rqLUN | Cmd check2 
(00h) (01h) 


Addresses OOh-OFh and FOh-FFh are reserved for DC functions and will not be used for IPM devices on the 
IPMB. These addresses can therefore be skipped if using the Broadcast Get Device ID command to scan for IPM 
devices. The remaining fields follow the regular IPMB definitions. 


In order to speed the discovery process on the IPMB, a controller should drop off the bus as soon as it sees that 
the rsSA in the command doesn’t match its rsSA. 
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21. Firmware Firewall & Command Discovery 


Commands 


The following sections provide the specifications for the commands that support the Firmware Firewall capability. 


Table 21-, Firmware Firewall Commands 


| Section 
Command Defined O/M 
Get NetFn Support 21.2 011,3] 
Get Command Support 21.3 ok 
Get Command Sub-function Support 21.4 ons] 
Get Configurable Commands 21.5 OF! 
Get Configurable Command Sub-functions 21.6 OP] 
Set Command Enables 217 O 
Get Command Enables 0 OF! 
Set Command Sub-function Enables 21.9 OF! 
Get Command Sub-function Enables 21.10 OF! 
Get OEM NetFn IANA Support 2141 OU 24 


1. Mandatory on any channel/interface to the BMC on which a typically mandatory 


command can be or is disabled for firmware firewall purposes. 


2. Mandatory on any channel/interface to the BMC on which the Set Command 
Enables command is implemented. The Set Command Enables, Get Command 
Enables, Set Command Sub-function Enables, and Get Command Sub-function 
Enables commands must be implemented as a set. 

3. The Get NetFn Support, Get Command Support, and Get Command Sub-function 
Support commands must be implemented as a set. 


4. Mandatory if OEM network functions 2Ch-2Dh or 2Eh-2Fh are utilized on 
management controller and firmware firewall is implemented. 


21.1 Completion Codes with Firmware Firewall 


When Firmware Firewall is used, the “D4h” completion code should be returned for any commands that are not 


available because of a security-based restriction. Commands that would normally be available (mandatory 


commands, or optional commands that are mandatory because they are required by another command or as part of 
an optional feature) but are un-available because they have been disabled via the Set Command Enables command 
should return D4h if an attempt is made to execute them. Similarly, a new completion code, *D6h”, can be used to 
indicate that a normally available command sub-function cannot be configured due to a security-based restriction. 
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21.2 Get NetFn Support Command 


This command returns which NetFn and LUNs support commands on a given channel. Since command support 
can vary by channel, the Channel Number parameter is part of the request. 


IPMI Request Data 


IPMI Response Data 
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Table 21-, Get NetFn Support Command 


Channel Number 
[7:4] - reserved 
[3:0] - channel number. 
Oh-Bh, Fh = channel numbers 
Eh = retrieve information for channel this request was issued on. 
Completion Code 


LUN support 
[7:6] - LUN 3 (11b) support 
00b = no commands supported on LUN 3 (11b) 
01b = commands follow base IPMI specification. Commands exist on 
LUN, but no special restriction of command functions. 
Comands follow standard Optional/Mandatory specifications. 
10b = commands exist on LUN, but some commands/operations may 
be restricted by firewall configuration. 
11b = reserved 
[5:4] - LUN 2 (10b) support 
Note that a BMC uses LUN 10b for message bridging. The message 
bridging capability is enabled/disabled by enabling/disabling the Send 
Message command. 
00b = no commands supported on LUN 2 (10b) 
01b = commands follow base IPMI specification. Commands exist on 
LUN, but no special restriction of command functions. 
Comands follow standard Optional/Mandatory specifications. 
10b = commands exist on LUN, but some commands/operations may 
be restricted by firewall configuration. 
11b = reserved 
[3:2] - LUN 1 (01b) support 
[1:0] - LUN 0 (00b) support 


There are 32 possible Network Function (NetFn) pairs. The following bytes 
are treated as bitfields where each bit indicates the support for a given 
Network Function pair. Thus, it takes 4 bytes to fully list support for NetFn 
values under a given LUN. Since there are four possible LUNs for a 
management controller, a total of 16 bytes will return the settings for all four 
possible LUNs. Ob = NetFn pair is not used, 1b = NetFn pair is used 


byte 1, bit 0 corresponds to NetFn pair Oh,1h for LUN 00b 
byte 1, bit 7 corresponds to NetFn pair Eh,Fh for LUN 00b 
byte 2, bit 0 corresponds to NetFn pair 10h,11h for LUN 00b 
byte 2, bit 7 corresponds to NetFn pair 1Eh, 1Fh for LUN 00b 


byte 16, bit 0 corresponds to NetFn pair 30h, 31h for LUN 11b 
byte 16, bit 7 corresponds to NetFn pair 3Eh, 3Fh for LUN 11b 
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21.3 Get Command Support Command 


This command provides a way to get a list of which command values are available on a given channel for a given 
Network Function and LUN. System software can iterate using this command to determine what commands are 
supported on a given management controller. The command returns information for 128 command values at a 
time. Thus, two iterations of the command are required to get all information for a given channel/NetFn/LUN 


combination. 


IPMI Request Data 


IPMI Response Data 


Table 21-, Get Command Support Command 


Channel Number 
[7:4] - reserved 
[3:0] - channel number. 
Oh-Bh, Fh = channel numbers 
Eh = retrieve information for channel this request was issued on. 


[7:6] - Operation 
00b = return support mask for commands OOh through 7Fh. 
01b = return support mask for commands 80h through FFh. 
10b, 11b = reserved. 

[5:0] - NetFn. Network function code to look up command support for. The 
management controller will return the same values for odd or even 
NetFn values. Le the value for bit [0] is ignored. 


[#22] = reserved 
[1:0] - LUN 


For Network Function = 2Ch: 


Defining body code (See description for Network Function 2Ch/2Dh in Table 
5-1, Network Function Codes) 


For Network Function = 2Eh: 


OEM or group IANA supported for given Network Function code on returned 
LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 
5-1, Network Function Codes) 


Completion Code 


Support Mask 


These sixteen bytes form a 128-bit bitfield where each bit indicates 
support for a particular command value under the given NetFn. 


For each bit in the bitfield: 
Ob = indicates the command is available 
1b = indicates the command not available 


Depending on the value of the “Operation” parameter passed in the 
request: 

byte 1, bit 0 corresponds to command 00h or command 80h 

byte 1, bit 7 corresponds to command 07h or command 87h 


byte 16, bit 0 correspond to command 78h or command F8h 
byte 16, bit 7 corresponds to command 7Fh or command FFh 
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21.4 Get Command Sub-function Support Command 


This command is used to determine what sub-functions of a given command are presently available on the given 
channel. The command can also be used to find out specifically which version of the specification was used to 
define the command operation. The latest version of the specification that the command conforms to is what is 
used. For example, a command that is conformant with both the IPMI v1.5 and v2.0 versions of the specification 
shall be identified as and IPMI v2.0 command. 


Table 21-, Get Command Sub-function Support Command 
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Channel Number 

[7:4]- reserved 

[3:0] - channel number. 

Oh-Bh, Fh = channel numbers 

Eh = retrieve information for channel this request was issued on. 


[7:6] - reserved 

[5:0] - NetFn. Network function code to look up command support for. The 
management controller will return the same values for odd or even 
NetFn values. Le the value for bit [0] is ignored. 


[7:2]- reserved 
[1:0] - LUN 


[7:0] - CMD. Command number to return command sub-function information 
for. 


For Network Function = 2Ch: 


Defining body code (See description for Network Function 2Ch/2Dh in Table 
5-1, Network Function Codes) 


For Network Function = 2Eh: 


OEM or group IANA supported for given Network Function code on returned 
LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 
5-1, Network Function Codes) 


Completion Code 


Specification Type / Errata 

For IPMI Network Function not equal to 2Ch or 2Eh: 

[7:4] - Specification Type 
Oh = IPMI, 1h = IPMB, 2h = ICMB, all other = reserved 

[3:0] - Errata Version 
This field returns the errata document version that was used in 
defining the command’s operation. For IPMI specifications, this is the 
revision number of the IPMI errata that goes with the specification 
version and revision, below. The latest errata of the specification to 
which the command is conformant should be used. Use Oh if there is 
no errata document available at the time the command was defined. 

For IPMI Network Function equal 2Ch or 2Eh: 

[7:0] - OEM/Group/Defining Body specific. Specification Type/Errata info in 
this byte specified by OEM/group or Defining Body that specified the 
command. 


Specification Version 
This field returns the specification Version, in BCD format for which 
the command was specified. Bits 7:4 hold the most significant digit of 
the version, while bits 3:0 hold the least significant bits, e.g. a value of 
20h indicates version 2.0. The latest version number for the 
specification that the command is conformant to should be used. 


Specification Revision 
This field returns the specification Revision, in BCD format for which 
the command was specified. Bits 7:4 hold the most significant digit of 
the version, while bits 3:0 hold the least significant bits, e.g. a value of 
10h indicates version 1.0. The latest revision number for the 
specification that the command is conformant to should be used. 


Support Mask 1 (Is-byte first) 
These thirty-two bits form a bitfield where each bit indicates support 
for a particular sub-function for the given command. The bit offset 
corresponds to the number of the sub-function. 


indicates that a mandatory sub-function or option is unavailable. 
indicates that a mandatory sub-function or option is available. Ob is 
also used when a given offset is undefined. Thus, a command that 
implements all functions (mandatory and optional) will return all O's for 
the bitfield. See Table H-1, Sub-function Number Assignments. 


bit for sub-function 31. 
bit for sub-function 30. 


bit for sub-function 1. 
bit for sub-function 0. 
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21.5 Get Configurable Commands Command 


This command returns the IPMI commands that can be enabled/disabled via the Set Command Enables command 
for a given channel/NetFn/LUN. 


Table 21-, Get Configurable Commands Command 


IPMI Request Data 


IPMI Response Data 
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Channel Number 
[7:4] - reserved 
[3:0] - channel number. 
Oh-Bh, Fh = channel numbers 
Eh = retrieve information for channel this request was issued on. 


[7:6] - Operation 
00b = return support mask for commands OOh through 7Fh. 
01b = return support mask for commands 80h through FFh. 
10b, 11b = reserved. 

[5:0] - NetFn. Network function code to look up command support for. The 
management controller will return the same values for odd or even 
NetFn values. l.e. the value for bit [0] is ignored. 


[7:2] - reserved 
[1:0] - LUN 


For Network Function = 2Ch: 


Defining body code (See description for Network Function 2Ch/2Dh in Table 
5-1, Network Function Codes) 


For Network Function = 2Eh: 


OEM or group IANA supported for given Network Function code on returned 
LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 
5-1, Network Function Codes) 


Completion Code 


Support Mask 
These sixteen bytes form a 128-bit bitfield where each bit indicates 
enable/disable support for a particular command value under the given 
NetFn. 


For each bit in the bitfield: 
Ob = indicates the command value is not configurable 
1b = indicates the command can be enabled/disabled 


Depending on the value of the “Operation” parameter passed in the 
request: 

byte 1, bit 0 corresponds to command 00h or command 80h 

byte 1, bit 7 corresponds to command 07h or command 87h 


byte 16, bit 0 correspond to command 78h or command F8h 
byte 16, bit 7 corresponds to command 7Fh or command FFh 
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21.6 Get Configurable Command Sub-functions Command 


This command enables software to discover which command sub-functions can be enabled/disabled via the Set 
Command Sub-function Enables command. 


Table 21-, Get Configurable Command Sub-functions Command 


IPMI Request Data Channel Number 

[7:4] - reserved 

[3:0] - channel number. 

Oh-Bh, Fh = channel numbers 

Eh = retrieve information for channel this request was issued on. 

[7:6] - reserved 

[5:0] - NetFn. Network function code to look up command support for. The 

management controller will return the same values for odd or even 

NetFn values. Le the value for bit [0] is ignored. 

[7:2] - reserved 

[1:0] - LUN 

[7:0] - CMD. Command number to return command sub-function information 
for. 

For Network Function = 2Ch: 

Defining body code (See description for Network Function 2Ch/2Dh in Table 

5-1, Network Function Codes) 

For Network Function = 2Eh: 

OEM or group IANA supported for given Network Function code on returned 

LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 

5-1, Network Function Codes) 

IPMI Response Data Completion Code 

Support Mask (Is-byte first) 
These thirty-two bits form a bitfield where each bit indicates support for a 
particular sub-function for the given command. The bit offset 
corresponds to the number of the sub-function. See Table H-1, Sub- 
function Number Assignments. 


1b indicates that the sub-function can be enabled/disabled. 
Ob indicates that the sub-function is not configurable, or is unavailable. Ob is 
also used for unspecified/reserved sub-function numbers. 


[31] - bit for sub-function 31. 
[30] - bit for sub-function 30. 


[1] - bit for sub-function 1. 

[0] - bit for sub-function 0. 

These additional 32-bits, if present, form a bitfield where each bit indicates 
support for a particular sub-function for the given command, starting 
from sub-function 32. The bit offset corresponds to the number of the 
sub-function. See Table H-1, Sub-function Number Assignments. These 
bytes are not required to be returned unless the particular command has 
sub-functions number definitions >31. 


Software should assume that an implementation may return these bytes 
for any command, if the particular command does not have any sub- 
function numbers >31 specified. 


1b indicates that the sub-function can be enabled/disabled. 
Ob indicates that the sub-function is not configurable, or is unavailable. Ob is 
also used for unspecified/reserved sub-function numbers. 


[31] - bit for sub-function 63. 
[30] - bit for sub-function 62. 


[1] - bit for sub-function 33. 
[0] - bit for sub-function 32. 
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21.7 Set Command Enables Command 


This command enables software to enable/disable commands for a given channel/netFn/LUN. The command sets 
the enables/disables for a large group of commands simultaneously. Therefore, software must perform a read- 
modify-write operation to change a single command setting or any subset of the group. This can be accomplished 
by using the Get Command Enables command to get the present setting, then ‘OR-ing’ or ‘AND-ing’ in the 
desired change, and using the Set Command Enables command to set the change into the management controller. 


It is highly recommended that the implementation takes steps to prevent the Set Command Enables command 
from being used to disable itself. The Set Command Enables command should always be an ‘un-configurable’ 
command on at least one channel into the BMC. 
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Table 21-, Set Command Enables Command 


IPMI Request Data Channel Number 

[7:4] - reserved 

[3:0] - channel number. 

Oh-Bh, Fh = channel numbers 
Eh = retrieve information for channel this request was issued on. 

[7:6] - Operation. The enable/disable settings are non-volatile. The 
management controller must reject all new settings (must not change 
present settings) if there is any error in the command (non-zero 
completion code returned). 
00b = Set enable/disables for commands 00h through 7Fh. 
01b = Set enables/disables for commands 80h through FFh. 
10b, 11b = reserved. 

[5:0] - NetFn. Network function code to set command support for. The 
management controller will set the same values for odd or even NetFn 
values. l.e. the value for bit [0] is ignored. 

[7:2] - reserved 

[1:0] - LUN 

Enable/Disable Mask 

These sixteen bytes form a 128-bit bitfield where each bit controls the 
enable/disable of a particular command value under the given NetFn. 


For each bit in the bitfield: 
Ob = disables the command 
1b = enables the command 


Note that if a bit position corresponds to a command that is not 
configurable, the BMC will return an error if an attempt is made to 
change the enabled/disabled state for that command. l.e. if the bit is 
fixed at Ob, and error will be generated if an attempt is made to set it to 
1b, and vice versa. Software can use the Get Configurable Commands 
command and the Get Command Enables command together to 
process the bits for this command to ensure setting the correct state. 


Depending on the value of the “Operation” parameter passed in the 
request: 

byte 1, bit 0 corresponds to command 00h or command 80h 

byte 1, bit 7 corresponds to command 07h or command 87h 


byte 16, bit 0 correspond to command 78h or command F8h 
byte 16, bit 7 corresponds to command 7Fh or command FFh 
For Network Function = 2Ch: 


Defining body code (See description for Network Function 2Ch/2Dh in Table 
5-1, Network Function Codes) 

For Network Function = 2Eh: 

OEM or group IANA supported for given Network Function code on returned 
LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 
5-1, Network Function Codes) 

IPMI Response Data Completion Code 

Generic, plus following command-specific codes: 

80h = attempt to enable an unsupported or un-configurable command. 
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21.8 Get Command Enables Command 


This command enables software to determine which commands are enabled/disabled for a given 
channel/netFn/LUN. 


Table 21-, Get Command Enables Command 


IPMI Request Data Channel Number 
[7:4] - reserved 
[3:0] - channel number. 
Oh-Bh, Fh = channel numbers 
Eh = retrieve information for channel this request was issued on. 
[7:6] - Operation 
00b = Get enable/disables for commands 00h through 7Fh. 
01b = Get enables/disables for commands 80h through FFh. 
10b, 11b = reserved. 
[5:0] - NetFn. Network function code to look up command support for. The 
management controller will return the same values for odd or even 
NetFn values. Le the value for bit [0] is ignored. 
[7:2] - reserved 
[1:0] - LUN 
For Network Function = 2Ch: 
Defining body code (See description for Network Function 2Ch/2Dh in Table 
5-1, Network Function Codes) 
For Network Function = 2Eh: 
OEM or group IANA supported for given Network Function code on returned 
LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 
5-1, Network Function Codes) 
IPMI Response Data 1 Completion Code 


2:17 | Enable/Disable Mask 

These sixteen bytes form a 128-bit bitfield where each bit returns the 
enable/disable of a particular command value under the given NetFn. If 
a command is not supported at all, a Ob will be returned. 


For each bit in the bitfield: 
Ob = command is disabled or not supported 
1b = command is enabled 


Software can use the Get Command Support command to determine 
which are supported, and the Get Configurable Commands command to 
determine which commands are configurable. 


Depending on the value of the “Operation” parameter passed in the 
request: 

byte 1, bit 0 corresponds to command 00h or command 80h 

byte 1, bit 7 corresponds to command 07h or command 87h 


byte 16, bit 0 correspond to command 78h or command F8h 
byte 16, bit 7 corresponds to command 7Fh or command FFh 
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This command is used for enabling/disabling configurable sub-functions for the given command. 


Table 21-, Set Configurable Command Sub-function Enables Command 


IPMI Request Data 


Channel Number 

[7:4] - reserved 

[3:0] - channel number. 

Oh-Bh, Fh = channel numbers 

Eh = retrieve information for channel this request was issued on. 


[7:6] - reserved 

[5:0] - NetFn. Network function code to set command support for. The 
management controller will set the same values for odd or even NetFn 
values. l.e. the value for bit [0] is ignored. 


[7:2] - reserved 
[1:0] - LUN 


[7:0] - CMD. Command number to set command sub-function enables for. 


For Network Function not equal to 2Ch or 2Eh: 


Sub-Function Enables (Is-byte first). The enable/disable settings are non- 
volatile and take effect on successful completion of the command. The 
management controller must reject all new settings (must not change 
present settings) if there is any error in the command (non-zero 
completion code returned). 


These thirty-two bits form a bitfield where each bit indicates support for a 
particular sub-function for the given command. The bit offset 
corresponds to the number of the sub-function. 


enables the sub-function 

disables the sub-function. Ob is also used for un-configurable/reserved 
sub-function numbers. See Table H-1, Sub-function Number 
Assignments. 


bit for sub-function 31. 
bit for sub-function 30. 


bit for sub-function 1. 
bit for sub-function 0. 


These additional 32-bits, if present, form a bitfield where each bit indicates 
support for a particular sub-function for the given command, starting 
from sub-function 32. The bit offset corresponds to the number of the 
sub-function. 


Software only needs to send these bytes in the request if it is setting the 
configuration for sub-functions 32 or higher. Note Software should be 
prepared that that earlier implementations (pre- errata 3) may return an 
error completion code if these additional bytes are sent. In general, 
software should avoid sending these additional bytes unless it knows 
(e.g. via the Get Configurable Command Sub-Functions command) that 
the given command supports sub-functions >31. 


enables the sub-function 

disables the sub-function. Ob is also used for un-configurable/reserved 
sub-function numbers. See Table H-1, Sub-function Number 
Assignments. 


[31] - bit for sub-function 63. 
[30] - bit for sub-function 62. 


[1] - bit for sub-function 33. 
[0] - bit for sub-function 32. 
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For Network Function = 2Ch: 


Defining body code (See description for Network Function 2Ch/2Dh in Table 
5-1, Network Function Codes) 


Sub-Function Enables (see definition for bytes 5:8 for “Network Function not 
equal to 2Ch or 2Eh” case, above.) 


(10:13) 


These additional 32-bits, if present, form a bitfield where each bit indicates 
support for a particular sub-function for the given command, starting from sub- 
function 32. The bit offset corresponds to the number of the sub-function. (see 
definition for bytes 9:12 for “Network Function not equal to 2Ch or 2Eh” case, 
above.) 


For Network Function = 2Eh: 


OEM or group IANA supported for given Network Function code on returned 
LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 
5-1, Network Function Codes) 


Sub-Function Enables (see definition for bytes 5:8 for “Network Function not 
equal to 2Ch or 2Eh” case, above.) 


IPMI Response Data 
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These additional 32-bits, if present, form a bitfield where each bit indicates 
support for a particular sub-function for the given command, starting from sub- 
function 32. The bit offset corresponds to the number of the sub-function. (see 
definition for bytes 9:12 for “Network Function not equal to 2Ch or 2Eh” case, 
above.) 


Completion Code 


Generic, plus following command-specific completion codes: 
80h = attempt to enable an unsupported or un-configurable sub-function. 


21.10 Get Configurable Command Sub-function Enables Command 
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This command enables software to determine which sub-functions are enabled/disabled for a given command on 


the specified channel/netFn/LUN. 


Table 21-, Get Configurable Command Sub-function Enables Command 


IPMI Request Data 


Channel Number 

[7:4] - reserved 

[3:0] - channel number. 

Oh-Bh, Fh = channel numbers 

Eh = retrieve information for channel this request was issued on. 


[7:6] - reserved 

[5:0] - NetFn. Network function code to look up command support for. The 
management controller will return the same values for odd or even 
NetFn values. Le the value for bit [0] is ignored. 


[7:2] - reserved 
[1:0] - LUN 


[7:0] - CMD. Command number to set command sub-function enables for. 
For Network Function = 2Ch: 


Defining body code (See description for Network Function 2Ch/2Dh in Table 
5-1, Network Function Codes) 


For Network Function = 2Eh: 


IPMI Response Data 


OEM or group IANA supported for given Network Function code on returned 
LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 
5-1, Network Function Codes) 

Completion Code 

Generic, plus following command-specific completion codes: 

80h = attempt to enable an unsupported or un-configurable sub-function. 


Sub-Function Enables (Is-byte first) 
These thirty-two bits form a bitfield where each bit indicates support for a 
particular sub-function for the given command. The bit offset 
corresponds to the number of the sub-function. See Table H-1, Sub- 
function Number Assignments. 


1b sub-function is enabled 
Ob sub-function is disabled or is un-configurable/reserved. 


[31] - bit for sub-function 31. 
[30] - bit for sub-function 30. 


[1] - bit for sub-function 1. 
[0] - bit for sub-function 0. 


These additional 32-bits, if present, form a bitfield where each bit indicates 
support for a particular sub-function for the given command, starting 
from sub-function 32. The bit offset corresponds to the number of the 
sub-function. See Table H-1, Sub-function Number Assignments. These 
bytes are not required to be returned unless the particular command has 
sub-functions number definitions >31. 


Software should assume that an implementation may return these bytes 
for any command, if the particular command does not have any sub- 
function numbers >31 specified. 


1b ` sub-function is enabled 
Ob sub-function is disabled or is un-configurable/reserved. 


[31] - bit for sub-function 63. 
[30] - bit for sub-function 62. 


[1] - bit for sub-function 33. 
[0] - bit for sub-function 32. 
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21.11 Get OEM NetFn IANA Support Command 


This command returns the [ANA Enterprise Number that is used to identify the OEM or Group that has defined 
functionality under Network Function codes 2Ch/2Dh, or 2Eh/2Fh. The command can be iterated if there is more 
than one IANA associated with the given Network Function code. 


Table 21-, Get OEM NetFn IANA Support Command 


IPMI Request Data Channel Number 
[7:4] - reserved 
[3:0] - channel number. 
Oh-Bh, Fh = channel numbers 
Eh = retrieve information for channel this request was issued on. 
Network Function (NetFn) code 
[7:6] - reserved. 
[5:0] - Network Function to get OEM IANA info for. Legal values are: 
2Ch = “Group Extension” Network Function (codes 2Ch,2Dh) 
2Eh = “OEM/Group” Network Function (codes 2Eh, 2Dh) 
all other = reserved 
List Index 
[7:6] - reserved 
[5:0] - List Index. 0 gets first IANA. Increment until last IANA is returned 
IPMI Response Data Completion Code 
[7]- 1b=last IANA 
[6:0] - reserved 
LUN support 
[7:6] - LUN 3 (11b) support 
00b = no commands supported on LUN 3 (11b) 
01b = commands follow base IPMI specification. Commands exist on 
LUN, but no special restriction of command functions. 
Comands follow standard Optional/Mandatory specifications. 
10b = commands exist on LUN, but some commands/operations may 
be restricted by firewall configuration. 
11b = reserved 
[5:4] - LUN 2 (10b) support 
Note that a BMC uses LUN 10b for message bridging. The message 
bridging capability is enabled/disabled by enabling/disabling the Send 
Message command. 
00b = no commands supported on LUN 2 (10b) 
01b = commands follow base IPMI specification. Commands exist on 
LUN, but no special restriction of command functions. 
Comands follow standard Optional/Mandatory specifications. 
10b = commands exist on LUN, but some commands/operations may 
be restricted by firewall configuration. 
11b = reserved 
[3:2] - LUN 1 (01b) support 
[1:0] - LUN 0 (00b) support 
For Network Function = 2Ch: 
Defining body code (See description for Network Function 2Ch/2Dh in Table 
5-1, Network Function Codes) 
For Network Function = 2Eh: 
OEM or group IANA supported for given Network Function code on returned 
LUNs. LS byte first. (See description for Network Function 2Eh/2Fh in Table 
5-1, Network Function Codes) 
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22. IPMI Messaging Support Commands 


This section defines the commands used to support the system messaging interfaces. This includes control bits for 
using the BMC as an Event Receiver and SEL Device. SMM Messaging and Event Message Buffer support is 
optional. Use of IPMI support for SMI’s and SMM Messaging is deprecated. Configuration interface support for 
enabling/disabling SMM Messaging and corresponding SMI has been removed from the specification. If SMM 
Messaging were implemented using the IPMI infrastructure, it would now be done as an OEM -proprietary 
capability. 


System software that is not explicitly aware of the particular platform’s use of SMI Messaging must assume that 
the any SMI options have been pre-configured by the controller, system BIOS, or other software. Therefore, run- 
time system software should not reconfigure SMI options, nor should it access the Event Message Buffer if it 
finds that Event Message Buffer interrupt is mapped to SMI. The effects of SMS accessing the Event Message 
Buffer when it is configured for SMI are unspecified. Refer to Appendix G - Command Assignments 


for the specification of the Network Function and Command (CMD) values and privilege levels for these 
commands. 


Table 22-, IPMI Messaging Support Commands 


commana | tie | om 
Command Defined O/M 


Enable Message Channel Receive 


Get Message 


Send Message 
Read Event Message Buffer 
Get System Interface Capabilities 
Get BT Interface Capabilities 


Master Write-Read 
Get System GUID 
Set System Info 
Get System Info 


Get Channel Authentication Capabilities 22.13 
Get Channel Cipher Suites 22.15 


= 


= 


Get Session Challenge 
Activate Session 
Set Session Privilege Level 
Close Session 
Get Session Info 
Get AuthCode 
Set Channel Access 
Get Channel Access 
Get Channel Info 
Set Channel Security Keys 
Set User Access 
Get User Access 
Set User Name 
Get User Name 22.29 
Set User Password 
1. | Optional if the System Interface is the only channel that’s implemented. 
2. Mandatory only if BT (block transfer) System Interface is used. 


= S| wil S| SS I] F| F| E = BS] =| BR) Gl Gl E Gi 
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Mandatory for a BMC that includes IPMB or PCI SMBus channels, or for any 
BMC or satellite controller that implements a private management bus for FRU 
SEEPROM access. 

Mandatory if session-based channels are supported 

Highly recommended for session-based channels. It is also recommended that 
the implementation support multiple of users with configurable usernames. 
Mandatory for IPMI v2.0 or later implementations of SSIF, and for any SSIF 
implementation if the BMC supports multi-part writes and reads. Recommended 
but not mandatory for KCS implementations. 

Mandatory if IPMI v2.0/RMCP+ session-based channels are implemented. 
Mandatory if Set System Info command is implemented. 


22.1 Set BMC Global Enables Command 


This command is used to enable message reception into Message Buffers, and any interrupt associated with that 
buffer getting full. The OEMO, OEM 1, and OEM 2 flags are available for definition by the OEM/System Integrator. 
Generic system management software must not alter these bits. 


Request Data 


Table 22-, Set BMC Global Enables Command 
byte data field 


This field is set to xxxx_100xb on power-up and system resets. If the 
implementation allows the receive message queue interrupt to be 
enabled/disabled, the default for bit 0 should be Ob.. 
[7] OEM 2 Enable. Generic system mgmt. software must do a ‘read-modify- 
write’ using the Get BMC Global Enables and Set BMC Global 
Enables to avoid altering this bit. 
[6] OEM 1 Enable. Generic system mgmt. software must do a ‘read-modify- 
write’ using the Get BMC Global Enables and Set BMC Global 
Enables to avoid altering this bit. 
[5] OEM 0 Enable. Generic system mgmt. software must do a ‘read-modify- 
write’ using the Get BMC Global Enables and Set BMC Global 
Enables to avoid altering this bit. 
[4] reserved 
[3] 1b = Enable System Event Logging (enables/disables logging of events 
to the SEL - with the exception of events received over the system 
interface. Event reception and logging via the system interface is 
always enabled.) SEL Logging is enabled by default whenever the 
BMC is first powered up. It’s recommended that this default state 
also be restored on system resets and power on. 
1b = Enable Event Message Buffer. Error completion code returned if 
written as ‘1’ and Event Message Buffer not supported. 
1b = Enable Event Message Buffer Full Interrupt 
1b = Enable Receive Message Queue Interrupt (this bit also controls 
whether KCS communication interrupts are enabled or disabled. An 
implementation is allowed to have this interrupt always enabled.) 


Note: If the Event Message Buffer Full or Receive Message Queue 
interrupt are not supported, an implementation can elect to return a 
CCh error completion code for the Set BMC Global Enables 
command if an attempt is made to enable the interrupt (this is the 
recommended implementation). 
Alternatively, the implementation can accept the command, but 
must return Ob for the corresponding bit in the Get BMC Global 
Enables. 


Response Data Completion Code. 


22.2 Get BMC Global Enables Command 


This command is used to retrieve the present setting of the Global Enables. The OEMO, OEM 1, and OEM 2 flags 
are available for definition by the OEM/System Integrator. Generic system management software must ignore these 


bits. 
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Table 22-, Get BMC Global Enables Command 
byte data field 


Reqguestbata [| "mi 
Response Data BEN Completion Code 


[7] - 1b = OEM 2 Enabled. 

[6] - 1b = OEM 1 Enabled. 

[5] - 1b = OEM 0 Enabled. 

[4] - reserved 

[3] - 1b = System Event Logging Enabled 

[2]- 1b Event Message Buffer Enabled 

[1] - 1b = Event Message Buffer Full Interrupt Enabled 

[0] - 1b = Receive Message Queue Interrupt Enabled (this bit also indicates 
whether KCS communication interrupt are enabled or disabled.) 


Note: If the Receive Message Queue and/or Event Message Full 
interrupts are not implemented the corresponding Interrupt Enabled 
status bit should always be returned as Ob. 


22.3 Clear Message Flags Command 


This command is used to flush unread data from the Receive Message Queue or Event Message Buffer. This will 
also clear the associated buffer full / message available flags. See Get Message Flags command. 


Table 22-, Clear Message Flags Command 
byte data field 

Request Data [7] - 1b = Clear OEM 2 

1b = Clear OEM 1 

1b = Clear OEM 0 

reserved 

1b = Clear watchdog pre-timeout interrupt flag 
reserved 


1b = Clear Event Message Buffer. 
[0] - 1b = Clear Receive Message Queue. 
Response Data Completion Code. 
Implementations are not required to return an error completion code if an 
attempt is made to clear the Event Message Buffer flag but the Event 
Message Buffer is not supported. 


22.4 Get Message Flags Command 


This command is used to retrieve the present ‘message available’ states. The OEMO, OEM 1, and OEM 2 flags are 
available for definition by the OEM/System Integrator. Generic system management software must ignore these bits. 
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Table 22-, Get Message Flags Command 
byte data field 


Request Data f 1 fe 
Response Data Completion Code. 
2 


Flags 
[7] - 1b = OEM 2 data available. 
1b = OEM 1 data available. 


1b = OEM 0 data available. 


reserved 

1b = Watchdog pre-timeout interrupt occurred 

reserved 

1b = Event Message Buffer Full. (Return as 0 if Event Message Buffer is 

not supported, or when the Event Message buffer is disabled.) 

1b = Receive Message Available. One or more messages ready for 
reading from Receive Message Queue 


22.5 Enable Message Channel Receive Command 


This command is used to enable/disable message reception into the Receive Message Queue from a given 
message channel. The command provides a mechanism to allow SMS to only receive messages from channels that 
it intends to process, and provides a disable mechanism in case the receive message queue is being erroneously or 
maliciously flooded with requests on a particular channel. It does not affect the ability for SMS to transmit on that 
channel. Only the SMS Message channel is enabled by default. All other channels must be explicitly enabled by 
BIOS or system software, as appropriate. It is recommended that a ‘Destination Unavailable’ completion code be 
returned if a request message to SMS is rejected because reception has been disabled. 


Table 22-, Enable Message Channel Receive Command 
byte data field 


Request Data 1 Channel Number 
[7:4]- reserved 
[3:0] - channel number 
2 


Channel State 

[7:2]- reserved 

[1:0] - 00b = disable channel 
01b = enable channel 
10b = get channel enable/disable state 
11b = reserved 


Response Data Completion Code 


2 Channel Number 

[7:4]- reserved 

[3:0] - channel number 
3 


Channel State 


[7:1]- reserved 
[0] - 1b = channel enabled 
Ob = channel disabled 


22.6 Get Message Command 
This command is used to get data from the Receive Message Queue. Refer to Table 6-8, IPMI Message and IPMB 


/ Private Bus Transaction Size Requirements, for information that can be used to determine the sizes of messages 
that need to be supported for a given Receive Message Queue implementation. 
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Software is responsible for reading all messages from the message queue even if the message is not the expected 
response to an earlier Send Message. System management software is responsible for matching responses up with 
requests. 


The Get Message command includes an “inferred privilege level” that is returned with the message. This can help 
avoid the need for software to implement a separate privilege-level and authentication mechanism. This works as 
follows: Suppose a user activates a session with a maximum privilege level of Administrator on a multi-session 
channel, and that an MD5 authentication type was negotiated. Also suppose that User-level authentication is 
disabled. A user that has User or higher privilege can place messages into the receive message queue by sending 
them to LUN 10b, or by using the Send Message command. If the packet has Authentication Type = MD5, the 
packet will be assigned an inferred privilege level based the on the present operating privilege level for the user 
(set using the Set Session Privilege Level command). If, before sending the packet, the user had set their privilege 
level to Operator, the packet would be assigned an inferred privilege level of Operator. (Note that this means an 
authenticated (signed) packet can be assigned different inferred privilege levels based on the present operating 
privilege set by the Set Session Privilege Level command.) If the message is received in a packet that has 
Authentication Type = None, the packet will be assigned an inferred privilege level of ‘User’, since that is the 
lowest privilege level for which that type of authentication is accepted. 


Now suppose that the remote user had used the receive message queue as a way to send a message to system 
management software that requests a soft shutdown of the operating system. The message would either have an 
inferred privilege level of ‘Operator’ or ‘User’ depending on whether it was sent as an authenticated message or 
not. System Management Software can then use that inferred privilege level as part of deciding whether to accept 
and process the message or not. For single-session channels, the inferred privilege level is always set to the 
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present operating privilege level. For session-less channels, the inferred privilege level is set to ‘None’, indicating 
that there was no IPMI-specified authentication operating on the channel from which the message was received. 


Table 22-, Get Message Command 
byte data field 


Request Data 


Response Data Completion Code 

generic, plus following command specific completion code: 

80h = data not available (queue / buffer empty) 
Implementation of this completion code is Mandatory. The code eliminates 
the need for system software to always check the Message Buffer Flags to 
see if there data left in the Receive Message Queue. If a non-OK, non-80h 
completion is encountered - software will need to check the Message Flags 
to get the empty/non-empty status of the Receive Message Queue. 

Channel Number 

[7:4] Inferred privilege level for message. 

When the BMC receives a message for the receive message queue, it 

assigns an ‘inferred privilege level’ to the message as follows: 


If the message is received from a session-based channel, it will initially be 
assigned a privilege level that matches the ‘maximum requested privilege 
level’ that was negotiated via the Activate Session command. 


If per-message authentication is enabled, but User-level authentication is 
disabled, the BMC will assign a level of ‘User’ to any messages that are 
received with an Authentication Type = none. (Note that per-message and 
user-level authentication options only apply to multi-session channels) 


The BMC will then lower the assigned privilege limit, if necessary, based on 
the present session privilege limit that was set via the Set Session Privilege 
Level command. 


If the channel is session-less (e.g. IPMB), the BMC will return ‘None’ for the 
privilege level. 


Oh = None (unspecified) 

1h = Callback level 

2h = User level 

3h = Operator level 

4h = Administrator level 

5h = OEM Proprietary level 


[3:0] channel number 
3:N | Message Data. Max. Length & format dependent on protocol associated with 
channel. 


The following table indicates the contents of the Message Data field from the Get Message response according to 
the Channel Type and Channel Protocol that was used to place the message in the Receive Message Queue. 


Table 22-, Get Message Data Fields 


Channel Message Data for received requests(RQ) 
Originating Channel Type Protocol and responses (RS) 
1 IPMB (12C) IPMBI! RO: netFn/rsLUN, chk1, rqSA, rqSeq/rqLUN, cmd, 
<data>, chk2 


RS: netFn/rqLUN, chk1, rsSA, rqSeq/rsLUN, cmd, 
completion code, <data>, chk2 


2 ICMB v1.0 ICMB-1.0 See Section 8.2, ICMB Bridge Commands in BMC 
using Channels 
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3 | ICMB v0.9 


ICMB-0.9 


See Section 8.2, ICMB Bridge Commands in BMC 
using Channels 


4 | 802.3 LAN 


IPMB 


RQ: Session Handle, rsSWID, netFn/rsLUN, chk1, 
rqSWID or rqSA, rqSeq/rqLUN, cmd, <data>, 
chk2 


RS: Session Handle, rqSWID, netFn/rsLUN, chk1, 
rsSWID or rsSA, rqSeq/rsLUN, cmd, completion 
code, <data>, chk2 


5 | Asynch. Serial/Modem 


IPMB (Basic 


RQ/RS: See row for Originating Channel Type = 802.3 


(RS-232) Mode, Terminal LAN 
Mode, and PPP | Note: When LUN 10b is used to deliver a message to 
Mode) SMS from a Terminal Mode remote console, the 
BMC inserts fixed values for the SWIDs and LUNs 
in the message. Messages from the remote 
console are always returned as coming from 
SWID 40h (81h) LUN 00b, and going to SMS 
SWID 20h (41h) LUN 00b. 
6 | Other LAN IPMB See row for Originating Channel Type = 802.3 LAN 
7 PCI SMBus IPMI-SMBus RQ: rsSA, Netfn(even)/rsLUN, 00h, rqSA, 
8 | SMBus v1.0/1.1 rqSeq/rqLUN, CMD, <data>, PEC 
9 | SMBus v2.0 RS: rqSA or rqSWID, NetFn(odd)/rqLUN, 00h, rsSA or 
rsSWID, rqSeq/rsLUN, CMD, completion code, 
<data>, PEC 
10 | reserved for USB 1.x n/a n/a 
11 | reserved for USB 2.x n/a n/a 
12 | System Interface BT, KCS, SMIC | RQ/RS: See row for Originating Channel Type = 802.3 


LAN. 


1. This message data matches the IPMB message format with the leading slave address omitted. The format includes 
checksums. In order to verify those checksums, they must be calculated as if 20h (BMC slave address) was the value that 
was used as the slave address when the checksums were calculated per [IPMB]. 20h shall always be used for the 
checksum calculation for the receive message queue data whenever IPMB is listed as the originating bus and with IPMB as 


the Channel Protocol. 


22.7 Send Message Command 


The Send Message command is used for bridging IPMI messages between channels, and between the system 
management software (SMS) and a given channel. Refer to 6.13, BMC Message Bridging, for information on 
how the Send Message command is used. 


For IPMI v2.0 the Send Message command has been updated to include the ability to indicate whether a 
message must be sent authenticated or with encryption (for target channels on which authentication and/or 
encryption are supported and configured). 
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Table 22-, Send Message Command 
byte data field 


Request Data Channel Number 

[7:6] 00b = No tracking. The BMC reformats the message for the selected channel but does not track 
the originating channel, sequence number, or address information. This option is typically 
used when software sends a message from the system interface to another media. 
Software will typically use ‘no tracking’ when it delivers sends a message from the system 
interface to another channel, such as IPMB. In this case, software will format the 
encapsulated message so that when it appears on the other channel, it will appear to have 
been directly originated by BMC LUN 10b. See 6.12.1, BMC LUN 10b Routing. 


Track Request. The BMC records the originating channel, sequence number, and 
addressing information for the requester, and then reformats the message for the protocol 
of the destination channel. When a response is returned, the BMC looks up the requester's 
information and format the response message with the framing and destination address 
information and reformats the response for delivery back to the requester. This option is 
used for delivering IPMI Request messages from non-SMS (non-system interface) 
channels. See 6.12.3, Send Message Command with Response Tracking. 


Send Raw. (optional) This option is primarily provided for test purposes. It may also be 
used for proprietary messaging purposes. The BMC simply delivers the encapsulated data 
to the selected channel in place of the IPMI Message data. Note that if the channel uses 
sessions, the first byte of the Message Data field must be a Session Handle. The BMC 
should return a non-zero completion code if an attempt is made to use this option for a 
given channel and the option is not supported. It is recommended that completion code 
CCh be returned for this condition. 


11b = reserved 


1b = Send message with encryption. BMC will return an error completion code if this encryption 
is unavailable. 

Ob = Encryption not required. The message will be sent unencrypted if that option is available 
under the given session. Otherwise, the message will be sent encrypted. 


1b = Send message with authentication. BMC will return an error completion code if this 
authentication is unavailable. 

Ob = Authentication not required. Note behavior is dependent on whether authentication is used 
is depending on whether the target channel is running an IPMI v1.5 or IPMI v2.0/RMCP+ 
session, as follows: 


IPMI v1.5 sessions will default to sending the message with authentication if that option is 
available for the session. 


IPMI v2.0/RMCP+ sessions will send the message unauthenticated if that option is 
available under the session. Otherwise, the message will be sent with authentication. 


[3:0] channel number to send message to. 


2:N | Message Data. Format dependent on target channel type. See Table 22-, Message Data for Send 
Message Command 


Response Data Completion Code 
generic, plus additional command-specific completion codes: 
80h = Invalid Session Handle. The session handle does not match up with any currently active 
sessions for this channel. 


If channel medium = IPMB, SMBus, or PCI Management Bus: 
(This status is recommended for applications that need to access low-level IC or SMBus devices.) 
81h = Lost Arbitration 
82h = Bus Error 
83h = NAK on Write 
Response Data 
This data will only be present when using the Send Message command to originate requests from 
IPMB or PCI Management Bus to other channels such as LAN or serial/modem. It is not present in the 
response to a Send Message command delivered via the System Interface. 
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NOTE: The BMC does not parse messages that are encapsulated in a Send Message command. Therefore, 
it does not know what privilege level should associated with an encapsulated message. Thus, 
messages that are sent to a session using the Send Message command are always output using the 
Authentication Type that was negotiated when the session was activated. 


to deliver an IPMI Message to different channel types. Note that in most cases the format of message information 
the Message Data field follows that used for the IPMB, with two typical exceptions: When the message is 
delivered to channels without physical slave devices, a software ID (SWID) field takes the place of the slave 


address field. When the message is delivered to a channel that supports sessions, the first byte of the message data 


holds a Session Handle. 


Table 22-, Message Data for Send Message Command 


Target Message Data field contents for Send Message 
Channel command for sending requests(RQ) and responses 
Target Channel Type Protocol (RS) 
1 IPMB (SCH IPMB RQ: rsSA, netFn/rsLUN, chk1, rqSA, rqSeq/rqLUN, 
cmd, <data>, chk2 
RS: rqSA, netFn/rqLUN, chk1, rsSA, rqSeq/rsLUN, 
cmd, completion code, <data>, chk2 
2 ICMB v1.0 ICMB-1.0 See Section 8.2, ICMB Bridge Commands in BMC 
using Channels 
3 | ICMB v0.9 ICMB-0.9 See Section 8.2, ICMB Bridge Commands in BMC 
using Channels 
4 | 802.3 LAN IPMB+session RQ: Session Handlel!l, rsSWID, netFn/rsLUN, chk1, 
header rqSWID or rqSA, rqSeq/rqLUN, cmd, <data>, 
chk2 
RS: Session Handlel'l, rqSWID, netFn/rsLUN, chk1, 
rsSWID or rsSA, rqSeq/rsLUN, cmd, 
completion code, <data>, chk2 
5 | Asynch. Serial/Modem IPMB (Basic RQ/RS: See Target Channel Type = 802.3 LAN 
(RS-232) Mode, Terminal | Note: Terminal mode has a single, fixed SWID for 
Mode, and PPP the remote console, software using Send 
Mode) Message to deliver a message to a terminal 
mode remote console should use their SWID or 
slave address as the source of the request or 
response, and the Terminal Mode SWID (40h) 
as the destination. 
6 | Other LAN IPMB See Target Channel Type = 802.3 LAN 
7 | PCI SMBus IPMI-SMBus See Target Channel Type = IPMB 
8 | SMBus v1.0/1.1 
9 | SMBus v2.0 
10 | reserved for USB 1.x n/a n/a 
11 | reserved for USB 2.x n/a n/a 
12 | System Interface RQ/RS: See Target Channel Type = IPMB 


Note: BMC adds Session Handle info when it puts 
the message into the Receive Message Queue. 


Session Handle. Identifies the particular active session for this channel. The session handle identifies a particular active 
session on the given channel. The BMC assigns a different value to each time a new session is activated. A typical 
implementation will keep track of the last value that was assigned and increment it before assigning it to a new active 


session when the Activate Session command has been accepted. Software must include this field for channels where the 


Get Channel Info command indicates that the channel supports sessions. 
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22.8 Read Event Message Buffer Command 


This command is used to retrieve the contents of the Event Message Buffer. Reading the buffer automatically 
clears the Event Message Buffer Full flag from the Get Message Flags command. 


Table 22-, Read Event Message Buffer Command 
byte data field 
Request Data 


Response Data Completion Code. 
generic, plus additional command-specific completion codes: 
80h = data not available (queue / buffer empty) 


2:17 | Message Data. 16 bytes of data in SEL Record format, per Table 32-, SEL 
Event Records. A dummy Record ID of FFFFh should be returned for events 
placed in the Event Message Buffer while event logging is disabled or if the 
SEL is full. System management software should ignore the record ID when 
event logging is disabled. 


22.9 Get System Interface Capabilities Command 

This command can be used to determine whether the SSIF supports multi-part transactions, and what size of IPMI 
messages can be transferred. The Get System Interface Capabilities command is mandatory for BMCs that 
implement multi-part writes or reads. Thus, software can assume that if the Get System Interface Capabilities 
command is not implemented, the interface only supports single-part writes and reads. 
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Table 22-, Get System Interface Capabilities Command 
byte data field 
Request Data System Interface Type 
[7:4] - reserved 
[3:0] - System Interface Type (For BT use the Get BT Interface Capabilities 
command) 
Oh = SSIF 
th =KCS 
2h = SMIC 
all other = reserved 
Response Data 
For System Interface Type = SSIF: 
[7:6] - Transaction support 
00b = only single-part reads/writes supported. 
O1b = multi-part reads/writes supported. Start and End 
transactions only. 
10b = multi-part reads/writes supported. Start, Middle, and 
End transactions supported. 
11b= reserved. 
reserved. 
PEC support. 
1b = implements PEC. BMC will start using PEC in read 
transactions after it receives any SSIF write transaction 
that includes a valid PEC. The BMC ceases using PEC 
if it receives an SSIF write transaction that does not 
include PEC. 
Ob = does not support PEC. Note that a BMC implementation 
may reject write transactions that include a PEC byte. 
[2:0] - SSIF Version 
000b = version 1 (version defined in this specification). 
Input message size in bytes. (1 based.) 
Number of bytes of IPMI message data that the BMC can accept. 
This number does not include slave address, SMBus length, 
PEC, or SMBus CMD bytes, just the IPMI message data. A BMC 
that just supports single-part writes would return 32 (20h) for this 
value. A BMC that supports multi-part Start and End would return 
a value from 33 to 64. A BMC that supports multi-part with Middle 
transactions would return a value from 65 to 255. 
Output message size in bytes. (1 based.) 
Maximum number of bytes of IPMI message data that can be 
read from the BMC. This number does not include slave address, 
SMBus length, PEC, SMBus CMD bytes, special bytes (such as 
the special bytes following the length byte in the multi-part read 
middle and end transactions) just the IPMI message data. A BMC 
that just supports single-part reads would return 20h (32) for this 
value. A BMC that supports multi-part Start and End would return 
a value from 33 to 62 (the reason this is 62 instead of 64 is that 
there are two special bytes after the length byte.) A BMC that 
supports multi-part with Middle transactions would return a value 
from 63 to 255. 
For System Interface Type = KCS or SMIC 


3 | [7:3] - reserved 
[2:0] - System Interface Version 
000b = version 1 (conformant with KCS or SMIC interface as 
defined in this specification). 
Input maximum message size in bytes. (1 based.) 


Largest number of bytes that can be transferred in a KCS 
FFh means 255 or more. 
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22.10 Get BT Interface Capabilities Command 


The BT interface includes a Get BT Interface Capabilities command that returns various characteristics of the 
interface, including buffer sizes, and multithreaded communications capabilities. 


Table 22-, Get BT Interface Capabilities Command 
byte data field 
Request Data [TT SSS SS 
Response Data 


Input (request) buffer message size in bytes. (1 based Vi 


Output (response) buffer message size in bytes. (1 based.) 


5 | BMC Request-to-Response time, in seconds, 1 based. 30 seconds, 
maximum. 


| 6 | Recommended retries (1 based). (see text for BT Interface) 


1. For Bytes 3 and 4 (Input and Output Buffer size), the buffer message size is the 
largest value allowed in first byte (length field) of any BT request or response 
message. For a send, this means if Get BT Interface Capabilities returns 255 in byte 
3 (input buffer size) the driver can actually write 256 bytes to the input buffer (adding 
one for the length byte (byte 1) that is sent in with the request.) 
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22.11 Master Write-Read Command 


This command can be used for low-level I’C/SMBus write, read, or write-read accesses to the IPMB or private 
busses behind a management controller. The command can also be used for providing low-level access to devices 
that provide an SMBus slave interface. 


Table 22-, Master Write-Read Command 


byte data field 


Request Data 

[7:4] channel number (Ignored when bus type = 1b) 

[3:1] bus ID, 0-based (always 000b for public bus [bus type = Ob]) 

[0] bus type: 

Ob = public (e.g. IPMB or PCI Management Bus. The channel number 
value is used to select the target bus.) 

1b = private bus (The bus ID value is used to select the target bus.) 

[7:1] - Slave Address 

[0] - reserved. Write as 0. 

Read count. Number of bytes to read, 1 based. 0 = no bytes to read. The 

maximum read count should be at least 34 bytes. This allows the command to 

be used for an SMBus Block Read. This is required if the command provides 

access to an SMBus or IPMB. Otherwise, if FRU SEEPROM devices are 

accessible, at least 31 bytes must be supported. Note that an implementation 

can support fewer bytes can be supported if none of the devices to be 

accessed can handle the recommended minimum. 


This allows the command to be used for an SMBus Block Write with PEC. 
Otherwise, if FRU SEEPROM devices are accessible, at least 31 bytes must 
be supported. Note that an implementation is allowed to support fewer bytes if 
none of the devices to can handle the recommended minimum. 


Response Data Completion Code 
A management controller shall return an error Completion Code if an attempt 


is made to access an unsupported bus. 
generic, plus following command specific codes: 

81h = Lost Arbitration 

82h = Bus Error 

83h = NAK on Write 

84h = Truncated Read 
Bytes read from specified slave address. This field will be absent if the read 
count is 0. The controller terminates the I?C transaction with a STOP condition 
after reading the requested number of bytes. 


22.12 Session Header Fields 


Whether the session header fields are present in a packet is based on whether the channel is specified as 
supporting multiple sessions or not. In addition, which session fields are present is based on the authentication 
type. Single-session connections and session-less channels do not include session header fields. 


Session header fields are present on all packets where the channel and connection mode is specified as 
supporting multiple sessions, even if the particular implementation only supports one session. The following 
tables for the Get System GUID, Get Channel Authentication Capabilities, Get Session Challenge, and Activate 
Session commands explicitly show ‘session header’ fields in gray. This is done because those commands can be 
executed prior to a session being activated, and therefore certain session header field values are handled 
differently than they are after a session is established. 


The grayed session header fields illustrate which session header fields are present and what their values are 
required to be, but they do not serve to specify the order or organization of those fields in the packet for a 
particular medium. Refer to the example packet format figures for (e.g. Table 13-, RMCP/RMCP+ Packet 
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Format for IPMI via Ethernet) for the specification of the organization and position of the session header bytes 
for a particular medium. 


The following applies to packets on connections that are specified with support for multiple sessions: 


Session header fields are present on all packets where the channel and connection mode is specified as 
supporting multiple sessions, even if the particular implementation only supports one session. 


Note that the command tables do not show the session header fields except for the Get Channel 
Authentication Capabilities, Get Session Challenge, and Activate Session commands. However, they are 
still required for all commands on a multi-session connection. 


The Authentication Code field in the session header may or may not be present based on the Authentication 
Type. The authentication code field is absent whenever the Authentication Type is NONE. Whether the 
authentication code field is present or not when the Authentication Type = OEM is dependent on the OEM 
identified in the Get Channel Authentication Capabilities command. 


If per-message authentication is turned off for the channel, only the Activate Session command would use a 
non-NONE authentication type and include an AuthCode signature. All other commands under the session 
are sent with Authentication Type = NONE. 


If per-message authentication is turned off and a packet is received that has a non-NONE authentication 
type, it will be accepted (if the authentication type is supported), however the implementation is not 
required to authenticate the packet. Note that an implementation may authenticate the packet, therefore the 
Authentication Code must be correct. 


If User authentication is turned off for the channel, the behavior is the same as if per-message 
authentication is turned off, except that only packets for commands that are enabled at User privilege level 
are sent with Authentication Type = NONE. All other packets must be authenticated per the Authentication 
Type used to activate the session. 


22.13 Get Channel Authentication Capabilities Command 


This command is sent in unauthenticated (clear) format. This command is used to retrieve capability information 
about the channel that the message is delivered over, or for a particular channel. The command returns the 
authentication algorithm support for the given privilege level. When activating a session, the privilege level 
passed in this command will normally be the same Requested Maximum Privilege level that will be used for a 
subsequent Activate Session command. 


BMC implementations of IP-based channels must support the Get Channel Authentication Capabilities Command 
using the IPMI v1.5 packet format. BMCs that support IPMI v2.0 RMCP+ must also support the command using 
the IPMI v2.0/RMCP+ format. 


The Get Channel Authentication Capabilities command can also be used as a no-op ‘Ping’ to keep a session from 
timing out. 
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Table 22-, Get Channel Authentication Capabilities Command 
Session Request Data authentication type = NONE / payload type = IPMI Message 
session seq# = null (0’s) 
Session ID = null (0's) 
AuthCode = NOT PRESENT 


IPMI Request Data Channel Number 
[7] - 1b = get IPMI v2.0+ extended data. If the given channel supports 
authentication but does not support RMCP+ (e.g. a serial 
channel), then the Response data should return with bit [5] of byte 
4 = Ob, byte 5 should return O1h, 
Ob = Backward compatible with IPMI v1.5. Response data only returns 
bytes 1:9, bit [7] of byte 3 (Authentication Type Support) and bit 
[5] of byte 4 returns as Ob, bit [5] of byte byte 5 returns OOh. 
[6:4] - reserved 
[3:0] - channel number. 
Oh-Bh, Fh = channel numbers 
Eh = retrieve information for channel this request was issued on. 
Requested Maximum Privilege Level 
[7:4] - reserved 
[3:0] - requested privilege level 
Oh = reserved 
1h = Callback level 
2h = User level 
3h = Operator level 
4h = Administrator level 
5h = OEM Proprietary level 


Session Response Data authentication type = NONE / payload type = IPMI Message 
session seq# = null (0’s) 
Session ID = null (0's) 
AuthCode = NOT PRESENT 
IPMI Response Data 1 Completion Code 
2 Channel Number 
Channel number that the Authentication Capabilities is being returned 
for. If the channel number in the request was set to Eh, this will return 
the channel number for the channel that the request was received on. 
3 Authentication Type Support 
Returns the setting of the Authentication Type Enable field from the 
configuration parameters for the given channel that corresponds to the 
Requested Maximum Privilege Level. 
[7] - 1b = IPMI v2.0+ extended capabilities available. See Extended 
Capabilities field, below. 
Ob = IPMI v1.5 support only. 
[6] - reserved 
[5:0] -IPMI v1.5 Authentication type(s) enabled for given Requested Maximum 
Privilege Level 
All bits: 1b = supported 
Ob = authentication type not available for use. 


[5] - OEM proprietary (per OEM identified by the IANA OEM ID in 
the RMCP Ping Response) 

[4] - straight password / key 

[3] - reserved 

[2] - MD5 

[1] - MD2 

[0] - none 
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4 [7:6] - reserved 


[5] - KG status (two-key login status). Applies to v2.0/RMCP+ RAKP 
Authentication only. Otherwise, ignore as ‘reserved’. 
Ob = KG is set to default (all O's). User key KUID will be used in place of 
KG in RAKP. (Knowledge of KG not required for activating session.) 
1b = KG is set to non-zero value. (Knowledge of both KG and user 
password (if not anonymous login) required for activating session.) 


Following bits apply to IPMI v1.5 and v2.0: 
[4] - Per-message Authentication status 
Ob = Per-message Authentication is enabled. Packets to the BMC must 
be authenticated per Authentication Type used to activate the 
session, and User Level Authentication setting, following. 
1b = Per-message Authentication is disabled. Authentication Type ‘none’ 
accepted for packets to the BMC after the session has been 
activated. 


[3] - User Level Authentication status 
Ob = User Level Authentication is enabled. User Level commands must 
be authenticated per Authentication Type used to activate the 
session. 
1b = User Level Authentication is disabled. Authentication Type ‘none’ 
accepted for User Level commands to the BMC. 


[2:0] - Anonymous Login status 
This parameter returns values that tells the remote console whether 
there are users on the system that have ‘null’ usernames. This can be 
used to guide the way the remote console presents login options to the 
user. (see IPMI v1.5 specification sections 6.9.1, ‘Anonymous Login’ 
Convention and 6.9.2, Anonymous Login ) 


[2] - 1b = Non-null usernames enabled. (One or more users are enabled 
that have non-null usernames). 

[1] - 1b = Null usernames enabled (One or more users that have a null 
username, but non-null password, are presently enabled) 

[0] - 1b = Anonymous Login enabled (A user that has a null username 
and null password is presently enabled) 

5 For IPMI v1.5: - reserved 


For IPMI v2.0+: - Extended Capabilities 

[7:2] -reserved 

[1] - 1b = channel supports IPMI v2.0 connections. 

[0] - 1b = channel supports IPMI v1.5 connections. 

6:8 |OEMID 

IANA Enterprise Number for OEM/Organization that specified the 
particular OEM Authentication Type for RMCP. Least significant byte 
first. 

Return 00h, 00h, 00h if no OEM authentication type available. 


9 OEM auxiliary data. 

Additional OEM-specific information for the OEM Authentication Type for 
RMCP. 

Return 00h if no OEM authentication type available. 


22.14 Get System GUID Command 


This optional, though highly recommended, command can be used to return a GUID (Globally Unique ID), also 
referred to as a UUID (Universally Unique IDentifier), for the managed system to support the remote discovery 
process and other operations. The format of the ID follows the octet format specified in [RFC4122]. [RFC4122] 
specifies four different versions of UUID formats and generation algorithms suitable for use for a GUID in IPMI. 
These are version I (0001b) “time based”, and three ‘name-based’ versions: version 3 (0011b) “MD5 hash”, 
version 4 (0100b) “Pseudo-random”, and version 5 *SHA1 hash”. At present [SMBIOS] does not specify a 
particular specification or version for UUID generation. In general, if this remains unspecified the version I 
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format is recommended by the IPMI Specification for new system implementations. However, versions 3, 4, or 5 
formats are also allowed. A System GUID should not change over the lifetime of the system. 


If the BMC is on a removable card that can be moved to another system, the vendor of the card or system vendor 
should provide a mechanism for generating a new System GUID or retrieving the SMBIOS UUID from the given 
system. 


Since the GUID is typically ‘permanently’ assigned to a system, an interface that would allow the GUID to be 
configured or changed is not specified. For systems that support [SMBIOS] the System GUID that is returned by 
the BMC should match the UUID field value in the SMBIOS System Information (Type 1) record. 


The session header (Session Request data and Session Response Data) values shown in the following table 
illustrate the values that would be used to execute a Get System GUID Command outside of an active session. The 
Get System GUID will always be accepted outside of an active session. The Get System GUID command can also 
be executed within the context of an active session (providing the user is operating at higher than ‘Callback’ 
privilege). When the Get System GUID command is executed in the context of an active session, the session 
header fields must have correct values according to the authentication, Session ID, and session sequence number 
information that was negotiated for the session. 


Table 22-, Get System GUID Command 
Session Request Data authentication type = NONE 
session seq# = null (0’s) 
Session ID = null (0's) 
AuthCode = NOT PRESENT 


Request Data 
Session Response Data authentication type = NONE 
session seq# = null (0's) 
Session ID = null (0's) 
AuthCode = NOT PRESENT 
Response Data Completion Code 


GUID bytes 1 through 16. See Table 20-, GUID Format. 


22.14a Set System Info Parameters Command 


This command is used for setting system information parameters such as system name and BIOS/system firmware 
revision information. 


Table 22-16a, Set System Info Parameters Command 
byte data field 


Request Data 1 Parameter selector 
2:N | Configuration parameter data, per Table 22-16c, System Info Parameters 


Response Data Completion Code 
80h = parameter not supported. 


81h = attempt to set the ‘set in progress’ value (in parameter #0) when not in 
the ‘set complete’ state. (This completion code provides a way to 
recognize that another party has already ‘claimed’ the parameters) 
82h = attempt to write read-only parameter 
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22.14b Get System Info Parameters Command 


This command is used for retrieving system information parameters from the Set System Info Parameters 
command. 


Table 22-16b, Get System Info Parameters Command 


Request Data 


Response Data 


byte data field 


[7] - Ob = get parameter 
1b = get parameter revision only. 
[6:0] - reserved 


Parameter selector 


Set Selector. Selects a given set of parameters under a given Parameter 
selector value. 00h if parameter doesn't use a Set Selector. 


Block Selector (00h if parameter does not require a block number) 


Completion Code. 

Generic codes, plus following command-specific completion code(s): 

80h = parameter not supported. 

[7:0] - Parameter revision. 

Format: MSN = present revision. LSN = oldest revision parameter is backward 
compatible with. 11h for parameters in this specification. 

The following data bytes are not returned when the ‘get parameter revision 
only’ bit is 1b. 


Configuration parameter data, per Table 22-16c, System Info Parameters 

If the rollback feature is implemented, the BMC makes a copy of the existing 
parameters when the ‘set in progress’ state becomes asserted (See the Set In 
Progress parameter #0). While the ‘set in progress’ state is active, the BMC 
will return data from this copy of the parameters, plus any uncommitted 
changes that were made to the data. Otherwise, the BMC returns parameter 
data from non-volatile storage. 


Table 22-16c, System Info Parameters 


Parameter Parameter Data (non-volatile unless otherwise noted)!!! 
Set In Progress data 1 This parameter is used to indicate when any of the following parameters 
(volatile) are being updated, and when the updates are completed. The bit is primarily 


provided to alert software that some other software or utility is in the process of 

making changes to the data. 

An implementation can also elect to provide a ‘rollback’ feature that uses this 

information to decide whether to ‘roll back’ to the previous configuration information, 

or to accept the configuration change. 

If used, the roll back shall restore all parameters to their previous state. Otherwise, 

the change shall take effect when the write occurs. 

[7:2] - reserved 

[1:0] - 00b = set complete. If a system reset or transition to powered down state 
occurs while ‘set in progress’ is active, the BMC will go to the ‘set 
complete’ state. If rollback is implemented, going directly to ‘set 
complete’ without first doing a ‘commit write’ will cause any pending 
write data to be discarded. 

01b = set in progress. This flag indicates that some utility or other software 
is presently doing writes to parameter data. It is a notification flag 
only, it is not a resource lock. The BMC does not provide any interlock 
mechanism that would prevent other software from writing parameter 
data while ‘set in progress’ value is present on these bits. 
10b = commit write (optional). This is only used if a rollback is implemented. 
The BMC will save the data that has been written since the last time 
the ‘set in progress’ and then go to the ‘set in progress’ state. An error 
completion code will be returned if this option is not supported. 
11b = reserved 


System Firmware 
version 


System Firmware Version string in text. 


System firmware that requires multiple strings to represent version information can 
separate those strings using 00h as the delimiter for ASCII+LATIN1 and UTF-8 
encoded string data, or 0000h for UNICODE encoded string data. 
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For IA32 and EMT64 utilizing non-EFI system firmware, it is recommended that four 
blocks (64 bytes) of storage be provided. For EFl-based systems, 256 bytes is 
recommended. 


Note: System firmware may optionally include a routine that checks during POST to 
see if this parameter is up-to-date with the present firmware version, and if not, 
update it automatically. Other implementations may elect to automatically update 
this parameter when system firmware updates occur. 


data 1 - set selector = 16-byte data block number to access, 0 based. Two data 
blocks (32-bytes) for string data required, at least three recommended. 
Number of effective characters will be dependent on the encoding 
selected in string data byte 1. 

data 2:17 - 16-byte block for system firmware name string data 


For the first block of string data (set selector = 0), the first two bytes indicate 
the encoding of the string and its overall length as follows: 
string data byte 1: 
[7:4] - reserved 
[3:0] - encoding 

Oh = ASCII+Latin1 

th = UTF-8 

2h = UNICODE 

all other = reserved. 


string data byte 2: 
[7:0] - string length (in bytes, 1-based) 


System name 


System Name. A name for the overall system to be associated with the BMC. This 
may or may not match other names that are used for the system. 


data 1 - set selector = 16-byte data block number to access, 0 based. Two data 
blocks (32-bytes) for string data required, at least three recommended. 
Number of effective characters will be dependent on the encoding 
selected in string data byte 1. 

data 2:17 - 16-byte block for system name string data 


For the first block of string data (set selector = 0), the first two string data 
bytes indicate the encoding of the string and its overall length as follows. There 
is no required value to be set or used for any bytes that are past the string 
length. 
string data byte 1: 
[7:4] - reserved 
[3:0] - encoding 

Oh = ASCII+Latin1 

1h = UTF-8 (Is-byte first) 

2h = UNICODE (Is-byte first) 

all other = reserved. 


string data byte 2: 
[7:0] - string length (in bytes, 1-based) 
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Primary Operating 
System Name 
(non-volatile) 


Primary Operating system name. The OS that the system boots to for this BMC 
according to the default configuration of its system firmware. 

(Note: in systems that may have multiple physical partitions, this reflects the OS for 
the partition that the given BMC is in. For systems that have virtual machine 
capability being utilized [where more than one virtual systems may be sharing a 
physical BMC], it is recommended that this value hold the name of the virtual 
machine monitor (VMM) software or VMM type) 


data 1 - set selector = 16-byte data block number to access, 0 based. Two data 
blocks (32-bytes) for string data required, at least three recommended. 
Number of effective characters will be dependent on the encoding 
selected in string data byte 1. 

data 2:17 - 16-byte block for system name string data 


For the first block of string data (set selector = 0), the first two bytes indicate 
the encoding of the string and its overall length as follows. There is no required 
value to be set or used for any bytes that are past the string length. 
string data byte 1: 
[7:4] - reserved 
[3:0] - encoding 

Oh = ASCII+Latin1 

th = UTF-8 

2h = UNICODE 

all other = reserved. 
string data byte 2: 
[7:0] - string length (in bytes, 1-based) 


Operating System 
Name 
(volatile) 


Present Operating system name. The name of the operating system that is presently 
running and able to access this BMC’s system interface. The BMC automatically 
clears this value by zeroing out the string length on system power cycles and resets. 


(Note: in systems that may have multiple physical partitions, this reflects the OS for 
the partition that the given BMC is in. For systems that have virtual machine 
capability being utilized [where more than one virtual systems may be sharing 
a physical BMC], it is recommended that this value hold the name of the virtual 
machine monitor (VMM) software or VMM type) 


data 1 - set selector = 16-byte data block number to access, 0 based. Two data 
blocks (32-bytes) for string data required, at least three recommended. 
Number of effective characters will be dependent on the encoding 
selected in string data byte 1. 

data 2:17 - 16-byte block for system name string data 


For the first block of string data (set selector = 1), the first two bytes indicate the 
encoding of the string and its overall length as follows: 
string data byte 1: 
[7:4] - reserved 
[3:0] - encoding 
Oh = ASCII+Latin1 
th = UTF-8 
2h = UNICODE 
all other = reserved. 


string data byte 2: 
[7:0] - string length (in bytes, 1-based) 


Present OS Version 


OS version string for the Present Operating system listed in parameter 4. Selector 


implemented can be 
r/w or read-only) 


number based, same as OS name. 
Volatile. The BMC automatically clears this value by zeroing out the string length on 
system power cycles and resets. 

BMC URL URL string of the general form (see [RFC3986]) 

(optional, if http(s)://<ip>:<port> or http(s)://<DNSname>:<port> 


non-volatile. 
Default = NULL string 


288 


Intelligent Platform Management Interface Specification 


Base OS/Hypervisor 7 URL for Base OS/Hypervisor use to report a management URL string of the general 
URL For Manageability form (see [RFC3986)}): 

(optional, if http(s)://<ip>:<port> or http(s)://<DNSname>:<port> 

implemented can be Volatile. The BMC automatically clears this value by zeroing out the string length on 
r/w or read-only) system power cycles and resets. 


OEM 192 | This range is available for special OEM system information parameters. 
255 
1. Choice of system manufacturing defaults for non-volatile parameters is left to the system manufacturer unless otherwise 
specified. 


22.15 Get Channel Cipher Suites Command 


This command can be executed prior to establishing a session with the BMC. The command is used to look up 
what authentication, integrity, and confidentiality algorithms are supported. The algorithms are used in 
combination as ‘Cipher Suites’. This command only applies to implementations that support IPMI v2.0/RMCP+ 
sessions. 


The data is accessed 16-bytes at a time starting from List Index field value of 0 in the request and then repeating 
the request incrementing the List Index field each time until fewer than 16-bytes of algorithm data (or no 
algorithm data) is returned in the response, or the maximum List Index value has been reached. 


A given Cipher Suite may only be available for establishing a session at a particular maximum privilege level or 
lower. For example, a Cipher Suite that has a privilege level of ‘Admin’ can therefore be used for any privilege 
level, while a privilege level of User can only be used for establish sessions with a Maximum Requested Privilege 
Level of User or Callback. 


Because the authentication algorithm specifies the steps for authenticating the user, it is a necessary part of 
session establishment. Therefore an authentication algorithm number is required for all Cipher Suites. It is 
possible that a given Cipher Suite may not specify use of an integrity or confidentiality algorithm. If the Cipher 
Suite has integrity and/or confidentiality of 'none', then all the same steps for establishing a session are used (open 
session request/response, RAKP messages) - but the integrity (AuthCode) and confidentiality fields will be absent 
in packets for that are sent under the session. 
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Table 22-, Get Channel Cipher Suites Command 


IPMI Request Data Channel Number 
[7:4] - reserved 
[3:0] - channel number. 
Oh-Bh, Fh = channel numbers 
Eh = retrieve information for channel this request was issued on. 
Payload Type. 
[7:6] - reserved 
[5:0] - Payload Type number 
Typically 00h (IPMI). 


The Payload Type number is used to look up the Security Algorithm support 
when establishing a separate session for a given payload type. 
List Index. 
[7] - 1b = list algorithms by Cipher Suite 
Ob = list supported algorithms!) 
[6] - reserved 
[5:0] - List index (00h-3Fh). Oh selects the first set of 16, 1h selects the next 
set of 16, and so on. 
00h = Get first set of algorithm numbers. The BMC returns sixteen (16) 
bytes at a time per index, starting from index OOh, until the list 
data is exhausted, at which point it will O bytes or <16 bytes of list 
data. 
IPMI Response Data Completion Code 


Channel Number 
Channel number that the Authentication Algorithms are being returned 
for. If the channel number in the request was set to Eh, this will return 
the channel number for the channel that the request was received on. 
Cipher Suite Record data bytes, per Table 22-, Cipher Suite Record Format. 
Record data is ‘packed’; there are no pad bytes between records. It is 
possible that record data will span across multiple List Index values. 


The BMC returns sixteen (16) bytes at a time per index, starting from index 
00h, until the list data is exhausted, at which point it will 0 bytes or <16 bytes 
of list data. 


1. When listing numbers for supported algorithms, the BMC returns a list of the algorithm 
numbers for each algorithm that the BMC supports on a given channel. Each algorithm 
is listed consecutively and only listed once. There is no requirement that the BMC 
return the algorithm numbers in any specific order. 


22.15.1 Cipher Suite Records 


The data from the Get Channel Cipher Suites command is issued as Cipher Suite records. Tag bits are used to 
delimit different fields in the record. Each record starts off with a “Start Of Record” byte. This byte can be 30h or 
31h, indicating that the Start Of Record byte is followed either by an Cipher Suite ID, or by a OEM Cipher Suite 
ID plus OEM IANA. 


Following the header bytes are algorithm number bytes for the different algorithms that form the Cipher Suite. 
Each byte is tagged with the type of algorithm the number is for. Cipher Suite records are required to list 
algorithms in the order: Authentication Algorithm number first, Integrity Algorithm numbers next, and 
Confidentiality Algorithm numbers last. 
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If more than one algorithm of a given type is listed in the Cipher Suite Record, then any one of the algorithms can 
be used in combination with the other types. For example, if a Cipher Suite response returns both MD5 and MD2 
as Authentication and Integrity algorithms, and xRC4 for confidentiality, then the allowed combinations are 
[MD2, MD2, xRC4], [MD2, MD5, xRC4], [MD5, MD2, xRC4], and [MD5, MDS, xRC4]. Le a remote console 
can negotiate for those combinations when establishing a session. 


Table 22-, Cipher Suite Record Format 


size Tag bits | Tag bits 
[7:6] [5:0] 
20r5 - This field starts off with either a COh or C1h "Start of Record" byte, depending on whether 

the Cipher Suite is a standard Cipher Suite ID or an OEM Cipher Suite, respectively 

Byte 1: 

[7:0] = 1100 0000b. Start of Record, Standard Cipher Suite 
Data following COh (1100 0000b) start of record byte: 
Byte 2 - Cipher Suite ID 
This value is used a numeric way of identifying the Cipher Suite on the platform. It's 
used in commands and configuration parameters that enable and disable Cipher 
Suites. See Table 22-, Cipher Suite IDs. 

[5:0] = 1100 0001b. Start or Record, OEM Cipher Suite 
Data following C1h (1100 0001) start of record byte: 
Byte 2 - OEM Cipher Suite ID 
See Table 22-, Cipher Suite IDs. 
Byte 3:5 - OEM IANA 
Least significant byte first. 3-byte IANA for the OEM or body that defined the Cipher 
Suite. 

1 00b [5:0] = Authentication Algorithm Number. 
A Cipher Suite is only allowed to utilize one Authentication algorithm. See Table 13-, 
Authentication Algorithm Numbers 
var 01b [5:0] = Integrity Algorithm Number(s). See Table 13-, Integrity Algorithm Numbers 
var 10b [5:0] = Confidentiality Algorithm Number(s). See Table 13-, Confidentiality Algorithm 
Numbers 


22.15.2 Cipher Suite IDs 


The following table provides the number ranges and assignments for Cipher Suite IDs. The Cipher Suite ID 
values are used as a way to identify different Cipher Suites in configuration parameters and IPMI commands. 


The OEM IDs do not correspond to a particular Cipher Suite, but are handles that can be used to identify the 
Cipher Suite on a particular implementation of a BMC. I.e. the OEM Cipher Suite corresponding to “80h” can 
be different from one BMC to the next. These handles can, however, be used in configuration parameters and 
commands the same way as the IPMI-defined Cipher Suite IDs. 


The Get Channel Cipher Suites command will return the algorithms used to form a given Cipher Suite (those 
numbers can then be used by a remote console in the commands for establishing a session). For OEM defined 
Cipher Suites, the Get Channel Cipher Suites command will also return the IANA for the OEM or body that 
defined the Cipher Suite. 
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Table 22-, Cipher Suite IDs 


Authentication Integrity Confidentiality 
ID characteristics Cipher Suite Algorithm Algorithm(s) Algorithm(s) 
0 "no password" 00h, 00h, 00h RAKP-none None None 
1 S 01h, 00h, 00h | RAKP-HMAC- None None 
2 S, A 01h, 01h, 00h | SHAT HMAC-SHA1-96 None 
3 S,A,E Oth, O1h, O1h AES-CBC-128 
4 S AE Oth, 01h, 02h xRC4-128 
5 S,A,E Oth, O1h, 03h xRC4-40 
6 = 02h, 00h, 00h | RAKP-HMAC-MD5 | None None 
ig S,A 02h, 02h, 00h HMAC-MD5-128 None 
8 S, A, E 02h, 02h, 01h AES-CBC-128 
9 S,A,E 02h, 02h, 02h xRC4-128 
10 SAE 02h, 02h, 03h xRC4-40 
11 8, 02h, 03h, 00h MD5-128 None 
12 S,A,E 02h, 03h, 01h AES-CBC-128 
13 S.A, E 02h, 03h, 02h xRC4-128 
14 S, A, E 02h, 03h, 03h xRC4-40 
15 S 03h, 00h, 00h | RAKP-HMAC- None None 
16 S,A 03h, 04h, 00h | SHA256 HMAC-SHA256- None 
17 S, A, E 03h, 04h, O1h 128 AES-CBC-128 
18 S AE 03h, 04h, 02h xRC4-128 
19 SA E 03h, 04h, 03h xRC4-40 
80h- OEM specified OEM specified | OEM specified OEM specified OEM specified 
BFh 
COh- reserved - - - x 
FEN 
Key: 


S = authenticated session setup (correct role, username and password/key required to establish session) 
A = authenticated payload data supported. 
E = authentication and encrypted payload data supported 


22.16 Get Session Challenge Command 


This command is sent in unauthenticated format. While a Session ID is returned from the response to the Get 


Session Challenge command, the session must be activated using the Activate Session command before it can be 


used for sending other authenticated commands. The Activate Session command provides the starting sequence 
number for subsequent messages under the session. 


When the management controller looks up user names the controller scans the names sequentially by user ID 


starting from User ID 1. Disabled user names are skipped. The scan stops when the first matching user name that 


is enabled for the channel is found. 
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Table 22-, Get Session Challenge Command 
byte data field 
Session Reguest Data authentication type - NONE 
session seq# = null (0’s) 
Session ID = null (0's) 
AuthCode = NOT PRESENT 


IPMI Request Data Authentication Type for Challenge 
[7:4] - reserved 
[3:0] - requested Authentication Type 
Oh = none. No hashing or authentication done on session packets. 
Authentication Code field is not present. 


1h = MD2 
2h = MD5 
3h = reserved 
4h = straight password / key 
5h = OEM proprietary 
all other = reserved 
User Name. Sixteen-bytes. All 0’s for null user name (User 1) 


Session Response Data authentication type = NONE 
session seq# = null (0's) 
Session ID = null (0's) 
AuthCode = NOT PRESENT 


IPMI Response Data Completion Code 
81h = invalid user name 
82h = null user name (User 1) not enabled 
Temporary Session ID. LS byte first. 
This is a provision for a temporary Session ID that can be given out to 
parties that have requested challenges, but have not yet activated a 
session. It can be used as a mechanism to help protect against denial of 
service attacks by grabbing all free Session IDs. 


Challenge string data 


22.17 Activate Session Command 


While a Session ID is returned from the response to the Get Session Challenge command, the session must be 
activated using the Activate Session command before it can be used for sending other authenticated commands. 


The initial Activate Session command is used by the remote console to set the starting sequence number for 
subsequent messages under the session. When the Activate Session command is issued (for a given Session ID) 
the outbound session sequence number is set by the remote console and can be any random value. 


For a given temporary Session ID, the BMC must accept Activate Session commands with a null session sequence 
number and silently discard all other commands targeted to that Session ID. This provision is to enable a remote 
console to retry the Activate Session command in case the response was lost. The BMC will continue to accept the 
Activate Session command with a null session sequence number until the first valid and appropriately 
authenticated command with a non-null session sequence number is received. (The non-null sequence number 
must also be within the range specified by the initial inbound sequence number). After which, all subsequent 
commands for the session must have appropriately incremented, non-null sequence number values, including any 
Activate Session commands that may be received during session operation. 


The remote console can use an Activate Session command to change the outbound session sequence number 
during session operation. The BMC may also elect to change its inbound session sequence number at that time, or 
may continue with the inbound session sequence number sequence already in progress. 
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Table 22-, Activate Session Command 
byte data field 


Session Reguest Data authentication type - from corresponding Get Session Challenge command. 


session seq# = null (O's) when in 'pre-session' phase, non-null afterward. See 
text. 

Session ID = Temporary Session ID value from corresponding Get Session 
Challenge command, or present Session ID if session already active 

AuthCode = present unless authentication type = None. See 22. 17.1, 
AuthCode Algorithms for information on calculating this field for 
authentication types that are not “None”. 


IPMI Request Data Authentication Type for session. The selected type will be used for session 
activation and for all subsequent authenticated packets under the 
session, unless ‘Per-message Authentication’ or ‘User Level 
Authentication’ are disabled. (See 6.12.4, Per-Message and User Level 
Authentication Disables, for more information.) 


[7:4] - reserved 
[3:0] - Authentication Type. This value must match with the Authentication 
Type used in the Get Session Challenge request for the session. In 
addition, for multi-session channels this value must also match the 
authentication type used in the Session Header. 
Oh = none. No hashing or authentication done on session packets. 
Authentication Code field is not present. 
1h = MD2 
2h = MD5 
3h = reserved 
4h = straight password / key 
5h = OEM proprietary 
all other = reserved 
Maximum privilege level requested. Indicates the highest privilege level that 
may be requested for this session. This privilege level must be less than 
or equal to the privilege limit for the channel and the privilege limit for the 
user in order for the Activate Session command to be successful 
(completion code = 00h). Once the Activate Session command has been 
successful, the requested privilege level becomes a ‘session limit’ that 
cannot be raised beyond the requested level, even if the user and/or 
channel privilege level limits would allow it. Le it takes precedence over 
the channel and user privilege level limits. 


[7:4] - reserved 
[3:0] - Requested Maximum Privilege Level 
Oh = reserved 
1h = Callback level 
2h = User level 
3h = Operator level 
4h = Administrator level 
5h = OEM Proprietary level 
all other = reserved 
For multi-session channels: (e.g. LAN channel): 
Challenge String data from corresponding Get Session Challenge 
response. 


For single-session channels that lack session header (e.g. serial/modem in 
Basic Mode): 
Clear text password or AuthCode. See 22.17.1, AuthCode Algorithms. 
Initial Outbound Sequence Number = Starting sequence number that remote 
console wants used for messages from the BMC. (LS byte first). Must be 
non-null in order to establish a session. 0000 0000h = reserved. 


If the Activate Session command is executed after a session has been 
established, the Outbound Sequence Number will be reset to the given 
value. This will take effect for the corresponding Activate Session 
response and subsequent commands under the session. 
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Session ID = value from request 


authentication type = value passed in from request data 


session seq# = Initial outbound sequence number from corresponding 
Activate Session request. 


AuthCode = present unless authentication type = None. See 22. 17.1, 
AuthCode Algorithms for information on calculating this field for 
authentication types that are not “None”. 

Completion Code 

OOh = success 

81h = No session slot available (BMC cannot accept any more sessions) 

82h = No slot available for given user. (Limit of user sessions allowed under 
that name has been reached) 

83h = No slot available to support user due to maximum privilege capability. 
(An implementation may only be able to support a certain number of 
sessions based on what authentication resources are required. For 
example, if User Level Authentication is disabled, an implementation 
may be able to allow a larger number of users that are limited to User 
Level privilege, than users that require higher privilege.) 

84h = session sequence number out-of-range 

85h = invalid Session ID in request 

86h = requested maximum privilege level exceeds user and/or channel 
privilege limit 


Authentication Type for remainder of session 
The primary use of this parameter is to report whether per-message 
authentication will be used for IPMI message packets that follow the 
Activate Session packet. Per-message authentication is a channel 
configuration option that is set using the Get User Name command. If 
per-message authentication is disabled, the Authentication Type will be 
returned as ‘none’, and all subsequent packets for the session can either 
use ‘none’ as the authentication type or use the Authentication Type that 
was used in the request. Otherwise this value will be set to the 
Authentication Type that was used in the request. Note that Activate 
Session requests and responses are always required to be 
authenticated per what is returned by the Get Session Challenge 
command for the user. 


[7:4] - reserved 
[3:0] - Authentication Type 
Oh = none. No hashing or authentication done on session packets. 
Authentication Code field is not present. 
1h = MD2 
2h = MD5 
3h = reserved 
4h = straight password / key 
5h = OEM proprietary 
all other = reserved 


Session ID - use this for remainder of session. While atypical, the BMC is 
allowed to change the Session ID from the one that passed in the 
request. 


Initial inbound seq# = Sequence number that BMC wants remote console to 
use for subsequent messages in the session. The BMC returns a non- 
null value for multi-session connections and returns null (all 0’s) for 
single-session connections. 


Maximum privilege level allowed for this session 
[7:4] - reserved 
[3:0] - Maximum Privilege Level allowed 

Oh = reserved 

1h = Callback level 

2h = User level 

3h = Operator level 

4h = Administrator level 

5h = OEM Proprietary level 

all other = reserved 
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22.17.1 AuthCode Algorithms 


The following table lists the AuthCode calculation mechanism and field usage for the Activate Session 
command, authenticated packets, and the Get AuthCode command. 


e Refer to the [RFC1319] and [RFC1321] for information on the MD2 and MD5 algorithms, respectively. 


e For the following table, ‘+’ indicates concatenation of data, and H( ) represents the application of the 
message digest algorithm to that data. 


e The data bytes are passed to the message-digest algorithm in the same order that they’re transmitted in the 
message / packet. 


e The password/key is 0 padded to 16-bytes for all specified authentication types. 
Table 22-, AuthCode Algorithms 


Authentication 
Type Algorithm 
Single Session AuthCode carried in IPMI message data for Activate Session Command 
straight AuthCode = password 
password 
MD2 AuthCode = H(password + temporary Session ID + challenge string+ password) 
MD5 AuthCode = H(password + temporary Session ID + challenge string+ password) 
Multi-Session AuthCode carried in session header for all ‘authenticated’ packets 
straight AuthCode=password 
password 
MD2 AuthCode = H(password + Session IDIT14 IPMI Message data + session_seq# + 
password) 
MD5 AuthCode = H(password + Session ID! + /PMI Message data + session_seq# + 
password) 
Get AuthCode AuthCode carried in IPMI message data, per command description 
straight See description of Get AuthCode command. 
password 
MD2 AuthCode = H(password + Get AuthCode data + password) 
MD5 AuthCode = H(password + Get AuthCode data + password) 


1. This will be the Temporary Session ID when calculating the AuthCode for the initial Activate Session command. 


22.18 Set Session Privilege Level Command 


This command is sent in authenticated format. When a session is activated, the session is set to an initial privilege 
level. A session that is activated at a maximum privilege level of Callback is set to an initial privilege level of 
Callback and cannot be changed. All other sessions are initially set to USER level, regardless of the maximum 
privilege level requested in the Activate Session command or RAKP Message 1. The remote console must ‘raise’ 
the privilege level of the session using this command in order to execute commands that require a greater-than- 
User level of privilege. 


This command cannot be used to set a privilege level higher than the lowest of the privilege level set for the user 
(via the Set User Access command) and the privilege limit for the channel that was set via the Set Channel Access 
command. Note that the specification allows a session to be used across multiple channels. The maximum 
privilege limit and authentication are based on the user privilege and channel limits. Since these can vary on a per 
channel basis, an implementation cannot simply assign a single privilege limit to a given session but must 
authenticate incoming messages according to the specific settings for the channel and the user on a per-channel 
basis. 
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Table 22-, Set Session Privilege Level Command 


IPMI Request Data 


IPMI Response Data 


Requested Privilege Level 
[7:4] - reserved 
[3:0] - Privilege Level 
Oh - no change, just return present privilege level 
th - reserved 
2h - change to USER level 
3h - change to OPERATOR level 
4h - change to ADMINISTRATOR level 
5h - change to OEM Proprietary level 
all other = reserved 
Completion Code. Generic, plus following command specific: 
80h = Requested level not available for this user 
81h = Requested level exceeds Channel and/or User Privilege Limit 
82h = Cannot disable User Level authentication 


New Privilege Level (or present level if ‘return present privilege level’ was 
selected.) 


22.19 Close Session Command 


This command is used to immediately terminate a session in progress. It is typically used to close the session that 
the user is communicating over, though it can be used to other terminate sessions in progress (provided that the 
user is Operating at the appropriate privilege level, or the command is executed over a local channel - e.g. the 


system interface). 


Table 22-24, Close Session Command 


byte 
Request Data 


data field 


Session ID. For IPMI v2.0/RMCP+ this is the Managed System Session ID 
value that was generated by the BMC, not the ID from the remote 
console. If Session ID = 0000_0000h then an implementation can 
optionally enable this command to take an additional byte of parameter 
data that allows a session handle to be used to close a session. 


Response Data 


Session Handle. (only present if Session ID = 0000_0000h) 


Completion Code 
87h = invalid Session ID in request 
88h = invalid Session Handle in request 


22.20 Get Session Info Command 


This command is used to get information regarding which users presently have active sessions, and, when 
available, addressing information for the party that has established the session. Note that a portion of the response 


is dependent on the type of channel. 


For IPMI v2.0, a previously reserved field has been defined to hold a value indicating whether a session operating 
on a channel of Channel Type = 802.3 LAN is presently using IPMI v1.5 or v2.0/RMCP+ protocols. 
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Table 22-, Get Session Info Command 


IPMI Request Data Session Index: 

This value is used to select entries in a logical ‘sessions’ table 
maintained by the management controller. Info for all active sessions 
can be retrieved by incrementing the session index from 1 to N, where N 
is the number of entries in the Active Sessions table. 

00h = Return info for active session associated with session this command was 

received over. 

N = get info for Nth active session 

FEh = Look up session info according to Session Handle passed in this request. 

FFh = Look up session info according to Session ID passed in this request. 

Present if Session Index = FEh: 

Session Handle. 00h = reserved. 

Present if Session Index = FFh: 

Session ID. ID of session to look up session information for. For IPMI 

v2.0/RMCP+ this is the Session ID value that was generated by the BMC, not 

the ID from the remote console. 

IPMI Response Data Completion Code 

Session Handle presently assigned to active session. FFh = reserved. Return 
OOh if no active session associated with given session index. 

Number of possible active sessions. This value reflects the number of possible 
entries (slots) in the sessions table. 

[7:6] - reserved 

[5:0] - session slot count. 1-based. 

Number of currently active sessions on all channels on this controller. 

[7:6] - reserved 

[5:0] - active session count. 1-based. 0 = no currently active sessions. 

The following parameters are returned only if there is an active session 

corresponding to the given session index: 

User ID for selected active session 

[7:6] - reserved. 

[5:0] - User ID. 000000b = reserved. 

Operating Privilege Level 

[7:4] - reserved 

[3:0] - present privilege level that user is operating at. 

[7:4] - Session protocol auxiliary data 
For Channel Type = 802.3 LAN: 

Oh = IPMI v1.5 
1h = IPMI v2.0/RMCP+ 

Channel that session was activated over. 

[3:0] - channel number 

The following bytes 8:18 are optionally returned if Channel Type = 802.3 LAN: 

IP Address of remote console (MS-byte first). Address that was received in the 
Activate Session command that activated the session. 

MAC Address (MS-byte first). Address that was received in the Activate Session 

command that activated the session. 

Port Number of remote console (LS-byte first). Port Number that was received 
in UDP packet that held the Activate Session command that activated the 
session (for IPMI v1.5 packets) or that was used for in the packet for 
RAKP Message 3 (for IPMI v2.0 / RMCP+ packets). 

The following bytes 8:13 are returned if Channel Type = asynch. serial/modem: 

Session / Channel Activity Type: 

0 = IPMI Messaging session active 

1 = Callback Messaging session active 

2 = Dial-out Alert active 

3 = TAP Page active 

Destination Selector for active call-out session. 0 otherwise. 

[7:4] - reserved 

[3:0] - Destination selector. Destination 0 is always present as a volatile 

destination that is used with the Alert Immediate command. 

If PPP connection: 

IP address of remote console. (MS-byte first) OOh, OOh, OOh, 00h otherwise. 

The following additional bytes 14:15 are returned if Channel Type = asynch. 
serial/modem and connection is PPP: 

Port Address of remote console (LS-byte first). Address that was received in the 
Activate Session command that activated the session. 
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22.21 Get AuthCode Command 


This command is used to send a block of data to the BMC, whereupon the BMC will return a hash of the data 
together concatenated with the internally stored password for the given channel and user. This command allows a 
remote console to send an AuthCode and data block to system software on a remote platform, whereby the system 
software can validate the AuthCode by comparing it with the AuthCode returned by the BMC. This enables the 
BMC to serve as a validation agent for remote requests that come through local system software instead of 
through a remote session directly with the BMC. 


The application of this command is beyond this specification. However, the following is an outline of potential 
use of this capability. Remote console software could request that system software perform a particular operation. 
In response, local system software could deliver a challenge string to the remote console, which would be required 
to hash it with the desired password and return the AuthCode to the local system software. The local system 
software would then perform the requested operation only if it found that the AuthCode matched the one returned 
by the BMC. The local software would typically implement mechanisms to bind the challenge string to the 
requested operation to ensure that the challenge string and AuthCode combination only applied to a given instance 
of the requested operation, and even from a particular remote console. 


e Managed system delivers a random number token, S, to the Console. In this example, the Console uses S to 
identify a particular request. The managed system tracks outstanding S values, and expires them either 
because a valid message was received from a Console that used that token, or because the token was not 
used within a specified interval. 


e Console determines: X = data to be authenticated 


K1 = 16-byte ‘signature’ of X and a sequence number = hash(X, S, SW Authentication Type). Where 
SW_Authentication_Type is any signature algorithm management software wishes to use for 
providing a signature given X and S. 


K2 = 16-byte hash of K1 and the password = hash(K1, PWD, Authentication_Type). Where 
Authentication_Type in this case is one of the supported Authentication Types for the given 
BMC. Table 22-, AuthCode Algorithms, specifies how the “Get AuthCode Data” (K1) and 
password data (PWD) are concatenated for processing according to Authentication_Type. Note 
that the hash algorithm for K1 does not need to be a BMC supported algorithm or match the 
algorithm used for K2. 


e Console sends X, S, and K2 to software agent on managed system. 


e Software agent on the managed system calculates K1 from X and S that it received by locally calculating 
K1=hash1(X, S, SW_Authentication_Type). The software also verifies that S is a valid outstanding token. 


e Managed system passes K1 to BMC. BMC internally looks up password based on the user ID passed in the 
Get Authcode Command and produces: K2gmc = hash(K1, PWD, Authentication Type) 


e Managed system accepts data if software agents finds that K2 = K2pmc. 
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Table 22-, Get AuthCode Command 
byte data field 


IPMI Request Data [7:6] - Authentication Type / Integrity Algorithm Number 
00b = IPMI v1.5 AuthCode Algorithms 
01b = IPMI v2.0/RMCP+ Algorithm Number 


For [7:6] = 00b, IPMI v1.5 AuthCode Number: 
[5:4] - reserved 
[3:0] - hash type 
Oh = reserved 
1h = MD2 
2h = MD5 
3h = reserved 
4h = Reserved (change from IPMI v1.5). This shall result in an error 
completion code. 
5h = OEM proprietary 
all other = reserved 


For [7:6] = 01b, IPMI v2.0/RMCP+ Integrity Algorithm Number 
[5:0] - Integrity Algorithm Number. See Table 13-, Integrity Algorithm 
Numbers. The User Password is used as the starting key for the 
Integrity Algorithm, instead of session-dependent keys such as the 


Session Integrity Key. The “none” Integrity Number (0) is illegal and shall 
result in an error completion code. 

Channel Number 

[7:4] - reserved 

[3:0] - Channel number 

User ID. (software will typically have to use the Get User Name command to 

look up the User ID from a username) 

[7:6] - reserved 

[5:0] - User ID 

data to hash (must be 16 bytes) 


IPMI Response Data Completion Code 


For IPMI v1.5 AuthCode Number: 
2:17 | AuthCode = See 22.17.1, AuthCode Algorithms. 
For IPMI v2.0 Integrity Algorithm Number 


Resultant hash, per selected Integrity algorithm. Up to 20 bytes. An 
implementation can elect to return a variable length field based on the size of 
the hash for the given integrity algorithm, or can return a fixed field where the 
hash data is followed by 00h bytes as needed to pad the data to 20 bytes. 
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22.22 Set Channel Access Command 


This command is used to configure whether channels are enabled or disabled, whether alerting is enabled or 
disabled for a channel, and to set which system modes channels are available under. This configuration is saved 
in non-volatile storage associated with the BMC. The choice of factory default setting for the non-volatile 
parameters is left to the implementer or system integrator. 


The active (volatile) settings can be overwritten to allow run-time software to make temporary changes to the 
access. The volatile settings are overwritten from the non-volatile settings whenever the system is reset or 
transitions to a powered off state. 


An implementation can elect to provide a subset of the possible Access Mode options. If a given Access Mode 
is not supported, the command-specific completion code 83h, access mode not supported, must be returned. 
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Table 22-, Set Channel Access Command 
byte data field 


Request Data 
2 


[7:4] - reserved 
[3:0] - Channel number 


[7:6] - 


[5] - 


[2:0] - 


00b = don't set or change Channel Access 

01b = set non-volatile Channel Access according to bits [5:0] 

10b = set volatile (active) setting of Channel Access according to bits 

[5:0] 

11b = reserved 

PEF Alerting Enable/Disable 

This bit globally gates whether PEF alerts can be issued from the given 

channel. Setting this to enable PEF alerting is a necessary part of 

enabling alerts for the channel, but for alerts to be generated the PEF 
and channel configuration must also be set to enable alerting. The 
setting this bit to 'enable' does not alter the PEF configuration or the 
alerting settings in the channel's configuration parameters. For 
example, if PEF is not configured for generating an alert, enabling PEF 
alerting with this bit will not change that configuration. Setting this bit to 

‘disable’ will block PEF -generated alerts regardless of the PEF and 

channel configuration parameters. 

Ob = enable PEF Alerting 

1b = disable PEF Alerting on this channel (the Alert Immediate 

command can still be used to generate alerts) 

Per-message Authentication Enable/Disable 

This bit is ignored for channels (e.g. serial/modem) that do not support 

Per-message Authentication. 

Ob = enable Per-message Authentication 

1b = disable Per-message Authentication. [Authentication required to 
activate any session on this channel, but authentication not used 
on subsequent packets for the session.] 

User Level Authentication Enable/Disable. 

Optional. Return a CCh ‘invalid data field’ error completion code if an 

attempt is made to set this bit, but the option is not supported. 

Ob = enable User Level Authentication. All User Level commands are 
to be authenticated per the Authentication Type that was 
negotiated when the session was activated. 

1b = disable User Level Authentication. Allow User Level commands to 
be executed without being authenticated. 


If the option to disable User Level Command authentication is 
accepted, the BMC will accept packets with Authentication Type 
set to None if they contain user level commands. 


For outgoing packets, the BMC returns responses with the same 
Authentication Type that was used for the request. 


Access Mode for IPMI messaging (PEF Alerting is enabled/disabled 
separately from IPMI messaging, see bit 5) 
000b = disabled 
channel disabled for IPMI messaging 
001b = pre-boot only 
channel only available when system is in a powered down state or 
in BIOS prior to start of boot. 
010b = always available 
channel always available for communication regardless of system 
mode. BIOS typically dedicates the serial connection to the BMC. 
011b = shared 
same as always available, but BIOS typically leaves the serial port 
available for software use. 
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Channel Privilege Level Limit. This value sets the maximum privilege level 
that can be accepted on the specified channel. 
[7:6] - OOb = don't set or change channel Privilege Level Limit 
01b = set non-volatile Privilege Level Limit according to bits [3:0] 
10b = set volatile setting of Privilege Level Limit according to bits [3:0] 
11b = reserved 


[5:4] - reserved 


[3:0] - Channel Privilege Level Limit 
Oh = reserved 
1h = CALLBACK level 
2h = USER level 
3h = OPERATOR level 
4h = ADMINISTRATOR level 
5h = OEM Proprietary level 
Response Data Completion Code 
generic, plus following command-specific completion codes: 
82h = set not supported on selected channel (e.g. channel is session- 
less.) 
83h = access mode not supported 
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22.23 Get Channel Access Command 


This command is used to return whether a given channel is enabled or disabled, whether alerting is enabled or 
disabled for the entire channel, and under what system modes the channel can be accessed. 


Table 22-, Get Channel Access Command 
byte data field 


Request Data [7:4] - reserved 
[3:0] - Channel number. 
[7:6] - OOb = reserved 
01b = get non-volatile Channel Access 
10b = get present volatile (active) setting of Channel Access 
11b = reserved 
[5:0] - reserved 
Response Data Completion Code 
generic, plus following command-specific completion codes: 
82h = Command not supported for selected channel (e.g. channel is 
session-less.) 
[7:6] - reserved 
[5] - Ob = Alerting enabled 
1b = Alerting disabled 
[4] - Per-message Authentication Enable/Disable 
This bit is unspecified for channels (e.g. serial/modem) that do not 
support Per-message Authentication. 
Ob = per message authentication enabled 
1b = per message authentication disabled 
[3] - User Level Authentication Enable 
Ob = User Level Authentication enabled. 
1b = User Level Authentication disabled. 


[2:0] - Access Mode 
Oh= disabled 


channel disabled for communication 
1h = pre-boot only 
channel only available when system is in a powered down state or 
in BIOS prior to start of boot. 
2h = always available 
channel always available for communication regardless of system 
mode. BIOS typically dedicates the serial connection to the BMC. 
shared 
same as always available, but BIOS typically leaves the serial port 
available for software use. 
Channel Privilege Level Limit. This value returns the maximum privilege level 
that can be accepted on the specified channel. 
[7:4] - reserved 
[3:0] - Channel Privilege Level Limit 
Oh = reserved 
1h = CALLBACK level 
2h = USER level 
3h = OPERATOR level 
4h = ADMINISTRATOR level 
5h = OEM Proprietary level 
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22.24 Get Channel Info Command 


This command returns media and protocol information about the given channel. The channel protocol may vary 
with changes to the configuration parameters associated with the channel. 


Table 22-, Get Channel Info Command 


IPMI Request Data [7:4] - reserved 
[3:0] - channel number. Use Eh to get information about the channel this 
command is being executed from. 
IPMI Response Data Completion Code 
[7:4] - reserved 
[3:0] - actual channel number. This value will typically match the channel 
number passed in the request, unless the request is for channel E, in 
which case the response returns the actual channel number. 
[7]- reserved 
[6:0] - 7-bit Channel Medium type: per Table 6-, Channel Medium Type 
Numbers 
Channel Protocol Type: 
[7:5] - reserved 
[4:0] - 5-bit Channel IPMI Messaging Protocol Type per Table 6-, Channel 
Protocol Type Numbers 
Session support 
[7:6] - 00b = channel is session-less 
01b = channel is single-session 
10b = channel is multi-session 
11b = channel is session-based (return this value if a channel could 
alternate between single- and multi-session operation, as can 
occur with a serial/modem channel that supports connection 
mode auto-detect) 


Number of sessions that have been activated on given channel. 
[5:0] - active session count. 1-based. 
00_0000b = no sessions have been activated on this channel. 
Vendor ID (IANA Enterprise Number) for OEM/Organization that specified the 


Channel Protocol. 

Least significant byte first. 

Returns the IPMI IANA for IPMI-specification defined, non-OEM protocol type 
numbers other than OEM. 


The IPMI Enterprise Number is: 7154 (decimal). 

This gives the values F2h, 1Bh, 00h for bytes 6 through 8, respectively. This 
value is returned for all channel protocols specified in this document, including 
PPP. 

Auxiliary Channel Info 


For Channel = Fh (System Interface) : 

byte 1: SMS Interrupt Type 
OOh-OFh = IRQ 0 through 15, respectively 
10h-13h = PCI A-D, respectively 
14h = SMI 
15h = SCI 
20h-5Fh = system interrupt 0 through 63, respectively 
60h = assigned by ACPI / Plug ‘n Play BIOS 
FFh = no interrupt / unspecified 
all other = reserved 

byte 2: Event Message Buffer Interrupt Type 
see values for byte 1 


For OEM channel types: 
byte 1:2 = OEM specified per OEM identified by Vendor ID field. 


All other channel types: 
byte 1:2 = reserved. 
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22.25 Set Channel Security Keys Command 


The Set Channel Security Keys command provides a standardized interface for initializing system unique keys that 
are used for the pseudo-random number generator key (Kp) and the key-generation key (Kc) used for RMCP+. 


Implementing the ability to set Kr is optional. The command is provided mainly to offer a common interface for 
BMCs that are not pre-configured with a KR values, or which may need their KR values to be restored if they are 
lost due to a data corruption or firmware update. 


The command includes a mechanism that allows specified keys to be ‘locked’. Once locked, the key value cannot 
be read back or rewritten via standard IPMI commands. It is possible, however, that a firmware update or re- 
installation procedure may cause the keys to be cleared or unlocked. Software utilities responsible for BMC initial 
installation and setup should check to see whether keys have been locked and if not, should initialize them 
appropriately and lock them. 


If this command is not supported, it indicates that the keys are either permanently pre-configured, or that they are 
only configurable via an OEM/BMC-specific mechanism. 


Table 22-, Set Channel Security Keys Command 
byte data field 


Reguest Data 1 Channel Number 
[7:4] - reserved 
[3:0] - Channel Number (Note: this command only applies to channels that 
support RMCP+, if the channel does not support RMCP+ the 
command will return an error completion code.) 
2 Operation 
[7:2] - reserved 
[1:0] - Operation 
00b = read key 
BMC returns value of specified key, provided key has not yet been 
locked. Some BMCs may allow the key to be re-written if it does 
not match the expected value. Other BMCs may only allow one 
‘set’ operation. If the key value has not yet been initialized, the 
BMC will return 0’s for the key value. Utility software responsible 
for BMC installation and initial setup can use this Operation to 
also check to see whether keys have been initialized and locked. 


O1b - set key 
BMC writes given key value to non-volatile storage. 


10b lock key 
BMC locks out modification or reading the key value. Once a key 
has been locked, it is not cannot be rewritten or read via IPMI 
specified commands. 


11b = reserved 
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3 Key ID 
[7:0] - key ID. 
00h = RMCP+ “KR” key (20 bytes). The “KR” key is used as a unique value for 
random number generation. Note: A BMC implementation is allowed to 
share a single KR value across all channels. A utility can set KR and 
lock it for one channel, and then verify it has been set and locked for 
any other channels by using this command to read the key from other 
channels and checking the ‘lock status’ field for each channel to see if 
it matches and is locked. 
01h = RMCP+ “KG” key (20 bytes). “KG” key acts as a value that is used for 
key exchange for the overall channel. This key cannot be locked. This 
is to ensure a password/key configuration utility can set its value. This 
value is used in conjunction with the user key values (passwords) in 
RAKP-HMAC-SHA1 and RAKP-HMAC-MD5 authentication. Le the 
remote console needs to have a-priori knowledge of both this key value 
and the user password setting, in order to establish a session. KG must 
be individually settable on each channel that supports RMCP+-. 
all other = reserved 
(4:M) | Key value. Value for specified key. Used for “set” Operation only. Otherwise, 
this field is not used in the request. The BMC will ignore any bytes following 
the ‘Key ID’ byte. 
Response Data Completion Code. Generic, plus following command-specific completion 
codes: 
80h = Cannot perform set / confirm. Key is locked (mandatory) 
81h = insufficient key bytes 
82h = too many key bytes 
83h = key value does not meet criteria for specified type of key 
84h = KR is not used. BMC uses a random number generation approach 
that does not require a KR value. 
7:2 - reserved. 


1:0 - lock status 
00b = key is not lockable. 
01b = key is locked. 
10b = key is unlocked. 
11b = reserved 


Key value. 

The BMC returns the specified key value when the Operation is set to “read 
key”. Otherwise, the BMC returns no additional bytes past the completion 
code. 


22.26 Set User Access Command 


This command is used to configure the privilege level and channel accessibility associated with a given user ID. 
If this command is not supported, then a single ‘null user’ (User 1) per channel is assumed and the privilege 
level and channel access are determined solely by the settings returned by the Get Channel Access Limits 
command. If implemented, this command must support at least the null user (User 1). The number of additional 
users supported is left to the implementer. 


Note: The limits set using the Set Channel Access command take precedence over the Set User Access 
command settings. That is, if a given channel is limited to User level then all users will be limited to User level 
operation regardless of what their User Access levels were set to using the Set User Access command. 


Note that changes made to the user access and privilege levels may not take affect until the next time the user 
establishes a session. 
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Table 22-, Set User Access Command 
byte data field 


Request Data Ob = do not change any of the following bits in this byte 
1b = enable changing the following bits in this byte 


User Restricted to Callback 

Ob = User Privilege Limit is determined by the User Privilege Limit 
parameter, below, for both callback and non-callback connections. 

1b = User Privilege Limit is determined by the User Privilege Limit 
parameter for callback connections, but is restricted to Callback 
level for non-callback connections. Thus, a user can only initiate a 
Callback when they ‘call in’ to the BMC, but once the callback 
connection has been made, the user could potentially establish a 
session as an Operator. 


User Link authentication enable/disable (used to enable whether this 
user’s name and password information will be used for link 
authentication, e.g. PPP CHAP) for the given channel. Link 
authentication itself is a global setting for the channel and is 
enabled/disabled via the serial/modem configuration parameters. 

Ob = disable user for link authentication 

1b = enable user for link authentication 


User IPMI Messaging enable/disable (used to enable/disable whether 
this user’s name and password information will be used for IPMI 
Messaging. In this case, “IPMI Messaging’ refers to the ability to 
execute generic IPMI commands that are not associated with a 
particular payload type. For example, if IPMI Messaging is disabled for 
a user, but that user is enabled for activating the SOL payload type, 
then IPMI commands associated with SOL and session management, 
such as Get SOL Configuration Parameters and Close Session are 
available, but generic IPMI commands such as Get SEL Time are 
unavailable.) 

Ob = disable user for IPMI Messaging 

1b = enable user for IPMI Messaging 


[3:0] - Channel Number 

User ID 

[7:6] - reserved. 

[5:0] - User ID. 000000b = reserved. 
User Limits 

[7:4] - reserved 


[3:0] - User Privilege Limit. (Determines the maximum privilege level that the 

user is allowed to switch to on the specified channel.) 

Oh = reserved 

1h = Callback 

2h = User 

3h = Operator 

4h = Administrator 

5h = OEM Proprietary 

Fh = NO ACCESS 
User Session Limit. (Optional) Sets how many simultaneous sessions can be 
activated with the username associated with this user. If not supported, the 
username can be used to activate as many simultaneous sessions as the 
implementation supports. 
Return a CCh ‘invalid data field’ error completion code if an attempt is made to 
set a non-zero value in this field, but the option is not supported. 
[7:4] - reserved 
[3:0] - User simultaneous session limit. 1-based. Oh = only limited by the 
implementations overall support for simultaneous sessions. 
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Response Data Completion Code. 
Note: an implementation will not return an error completion code if the user 
access level is set higher than the privilege limit for a given channel. If it is 


desired to bring attention to this condition, it is up to software to check the 
channel privilege limits set using the Set Channel Access command and 
provide notification of any mismatch. 


22.27 Get User Access Command 


This command is used to retrieve channel access information and enabled/disabled state for the given User ID. 
The command also returns information about the number of supported users. 
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Table 22-, Get User Access Command 
byte data field 


Reguest Data [7:4] - reserved 
[3:0] - Channel Number 
[7:6] - reserved 
[5:0] - User ID. 000000b = reserved. 
Response Data Completion Code. 
Note: an implementation will not return an error completion code if the user 
access level is set higher than the privilege limit for a given channel. If it is 
desired to bring attention to this condition, it is up to software to check the 
channel privilege limits and provide notification of the mis-match. 
Maximum number of User IDs. 1-based. Count includes User 1. A value of 1 
indicates only User 1 is supported. 
[7:6] - reserved 
[5:0] - maximum number of user IDs on this channel 
Count of currently enabled User IDs (1-based). A value of 0 indicates that all 
users, including User 1, are disabled. This is equivalent to disabling access to 
the channel. 
[7:6] - User ID Enable status (for IPMI v2.0 errata 3 and later 
implementations). 
00b = User ID enable status unspecified. (For backward compatibility 
with pre-errata 3 implementations. IPMI errata 3 and later 
implementations should return the 01b and 10b responses.) 
01b = User ID enabled via Set User Password command. 
10b = User ID disabled via Set User Password command. 
11b = reserved. 
[5:0] - count of currently enabled user IDs on this channel (Indicates how 
many User ID slots are presently in use.) 
Count of User IDs with fixed names, including User 1 (1-based). Fixed names 
in addition to User 1 are required to be associated with sequential user IDs 
starting from User ID 2. 
[7:6] - reserved. 
[5:0] - count of user IDs with fixed names on this channel 
Channel Access 
[7] - reserved. 
[6] - Ob = user access available during call-in or callback direct connection 
1b = user access available only during callback connection 


For pre- IPMI v2.0 errata 3 implementations: 
bits 5:4, following, are used for determining the 'count of currently enabled 
user IDs’ in byte 3. Either bit being set to 1b represents an ‘enabled user ID’. 


For IPMI v2.0 errata 3 and later implementations: 
The ‘count of enabled User IDs’ is based on the User IDs that are presently 
enabled as reflected in byte 3, bits [7:6], User ID Enable status. 


Note: Some pre- IPMI v2.0 errata 3 implementations may automatically clear 
bits [5:4], and may also prevent them from being set, while the User ID is 
disabled. IPMI v2.0 errata 3 and later implementations should not alter bits 
[5:4] based on whether a User ID is enabled or not. 


[5] - Ob = user disabled for link authentication 
1b = user enabled for link authentication 

[4] - Ob = user disabled for IPMI Messaging 
1b = user enabled for IPMI Messaging 


[3:0] - User Privilege Limit for given Channel 
Oh = reserved 
th = Callback 
2h = User 
3h = Operator 
4h = Administrator 
5h = OEM Proprietary 
Fh = NO ACCESS (Note: this value does not add to, or subtract from, 
the number of enabled user IDs) 
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22.28 Set User Name Command 


This command allows user names to be assigned to a given User ID. The names are stored as a logical array 
within non-volatile storage associated with the management controller. Names are stored and retrieved using the 
User ID as the index into the logical array. There is no configurable name for User ID 1. User ID 1 is reserved 
for the null user name, User 1. 


The management controller does not prevent duplicate usernames from being enabled for the same channel. It is 
the responsibility of configuration software to ensure that duplicate user names are not enabled simultaneously 
for the same channel. 


Having duplicate usernames will not cause functional problems with the BMC because the BMC will just use 
the first username match that it finds. However, it could be confusing to the user if they have duplicate 
usernames enabled for a given channel, since only the settings for the first encountered username would be used 
by the BMC. See 6.9, Users & Password Support for more information. 


Table 22-, Set User Name Command 
byte data field 


Request Data User ID 
[7:6] - reserved. 
[5:0] - User ID. 000000b = reserved. (User ID 1 is permanently associated 

with User 1, the null user name). 

User Name String in ASCII, 16 bytes, max. Strings with fewer than 16 
characters are terminated with a null (OOh) character and 00h padded to 16 
bytes. When the string is read back using the Get User Name command, 
those bytes shall be returned as 0’s. 


Response Data Completion Code. 


22.29 Get User Name Command 


This command is used to retrieve user name information that was set using the Set User Name command. 
Configuration software can use this command to retrieve user names. 


Table 22-, Get User Name Command 
byte data field 
Reguest Data User ID 
[7:6] - reserved. 
[5:0] - User ID to return name for. 000000b = reserved. 
Response Data Completion Code. 
User Name String in ASCII, 16 bytes, max. Strings of fewer than 16 
characters are returned with null (00h) characters filling in the remaining 
bytes. BMC does not check to see whether string data is ‘printable’ or not. 
Only character that BMC interprets is null (00h). 
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.30 Set User Password Command 


This command is used to set and change user passwords and to enable and disable User IDs. If no password 
protection is desired for a given user, the password must be stored as an ASCII null-string. The management 
controller firmware will force the remaining fifteen bytes to 00h and store the password as sixteen bytes of OOh. 


If this command is not supported, then the implication is that only User 1 with a fixed, null password is 
supported. 


The password is stored as a 16-byte or 20-byte (for IPMI v2.0/RMCP+) ‘octet string’. All values (0-255) are 
allowed for every byte. The management controller does not check the format or interpret values that are passed 
in with the Set User Password command. 


Software is allowed to place additional restrictions on what passwords can be entered, in which case it is the 
responsibility of configuration software and console software to stay in synch with that definition. For example, 
remote console software could restrict passwords to the printable ASCII character set in order to simplify direct 
keyboard entry. If this is done, any companion configuration utility should ensure that the user does not 
configure the managed system with non-printable passwords. Otherwise, it would be possible for the 
management controller to be configured with passwords that could not be entered via the remote console utility. 


Request Data 


Response Data 
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Table 22-, Set User Password Command 


data field 


User ID. 
For IPMI v2.0, the BMC shall support 20-byte passwords (keys) for alll 
supported user IDs that have configurable passwords. The BMC shall 
maintain an internal tag that indicates whether the password was set as 
a 16-byte or as a 20-byte password. 


A 16-byte password can be used in algorithms that call for a 20-byte 
password. In this case, the 16-byte password is padded with 0’s to 20- 
bytes. 


The ‘test password’ operation shall return the ‘test failed’ error 
completion code if an attempt is made to test a password that was 
stored as a 20-byte password as a 16-byte password (per ‘password 
size’ bit 7), and vice versa. 


A password that has been stored as a 20-byte password cannot be used 
for establishing an IPMI v1.5 session. If it is necessary to configure the 
same password for both IPMI v2.0 and IPMI v1.5 access, it must be set 
as a 16-byte password®. The password will be padded with O's as 
necessary for IPMI v2.0 / RMCP+ use. 


The ‘test password’ operation can be used to determine whether a 
password has been stored as 16-bytes or 20-bytes. 


[7] - password size 
1b = set 20-byte user password/key. 
Ob = set 16-byte user password/key (IPMI v1.5 backward compatible) 
[6] - reserved. 
[5:0] - User ID. 000000b = reserved. (User ID 1 is permanently associated 
with User 1, the null user name). 

[7:2] - reserved 
[1:0] - operation 

00b = disable user 

01b = enable user 

10b = set password 

11b = test password Compares the password data given in the request 

with the presently stored password and returns an OK completion code if 

there is a match. Otherwise, an error completion code is returned. (See the 

Completion Code description in the response data.) 
For password size = 16 bytes: 
Password data. This is a required, fixed length field when used for the set- 
and test password operations. If the password is entered as an ASCII string, it 
must be null (00h) terminated and 00h padded if the string is shorter than 16 
bytes. This field need not be present if the operation is ‘disable user’ or 
‘enable user’. If this field is present for those operations, the BMC will ignore 
the data. 
For password size = 20 bytes: 
20-byte Password data. This is a required, fixed length field when used for the 
set- and test password operations. If the password is entered as an ASCII 
string, it must be null (00h) terminated and 00h padded if the string is shorter 
than 20 bytes. This field need not be present if the operation is ‘disable user’ 
or ‘enable user’. If this field is present for those operations, the BMC will 
ignore the data. 
Completion Code. Generic, plus following command-specific completion 
codes: 

80h = (mandatory) password test failed. Password size correct, but 

password data does not match stored value. 
81h = (mandatory) password test failed. Wrong password size was used. 


Note that the same username is allowed to be used with different passwords on different channels. The BMC scans 
usernames until it finds the first one that is enabled for a particular channel. Thus, it is possible for a BMC implementation to 
allow being configured to allow a 20-byte password on one channel, and a 16-byte password on another channel for the same 
username. This requires multiple user entries. 
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23. IPMI LAN Commands 


This section defines the configuration and control commands that are specific to LAN channels. None of the 
commands in the following table are required unless a LAN channel is implemented. Refer to Appendix G - 


Command Assignments 


for the specification of the Network Function and Command (CMD) values and privilege levels for these 
commands. 


Table 23-, IPMI LAN Commands 

Section 

Command Defined 
Set LAN Configuration Parameters 23.1 
Get LAN Configuration Parameters 23.2 
Suspend BMC ARPs 23.3 
Get IP/UDP/RMCP Statistics 23.4 


1. Mandatory if LAN channel is supported. 
2. Mandatory if BMC autonomously generates Gratuitous ARPs 


23.1 Set LAN Configuration Parameters Command 


This command is used for setting parameters such as the network addressing information required for IPMI LAN 
operation. 


Table 23-, Set LAN Configuration Parameters Command 
byte data field 


Request Data 1 [7:4] - reserved 
[3:0] - Channel number. 


Parameter selector 


2 
Configuration parameter data, per Table 23-, LAN Configuration Parameters 


Response Data 1 Completion Code 


80h = parameter not supported. 

81h = attempt to set the ‘set in progress’ value (in parameter #0) when not in 
the ‘set complete’ state. (This completion code provides a way to 
recognize that another party has already ‘claimed’ the parameters) 

82h = attempt to write read-only parameter 

83h = attempt to read write-only parameter 
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23.2 Get LAN Configuration Parameters Command 


This command is used for retrieving the configuration parameters from the Set LAN Configuration command. 


Table 23-, Get LAN Configuration Parameters Command 
byte data field 


Request Data 


Response Data 


[7]- Ob = get parameter 

1b = get parameter revision only. 
[6:4] - reserved 
[3:0] - Channel number. 


Parameter selector 


Set Selector. Selects a given set of parameters under a given Parameter 
selector value. OOh if parameter doesn’t use a Set Selector. 


Block Selector (00h if parameter does not require a block number) 


Completion Code. 

Generic codes, plus following command-specific completion code(s): 

80h = parameter not supported. 

[7:0] - Parameter revision. 

Format: MSN = present revision. LSN = oldest revision parameter is backward 
compatible with. 11h for parameters in this specification. 

The following data bytes are not returned when the ‘get parameter revision 
only’ bit is 1b. 


Configuration parameter data, per Table 23-, LAN Configuration Parameters 
If the rollback feature is implemented, the BMC makes a copy of the existing 
parameters when the ‘set in progress’ state becomes asserted (See the Set In 
Progress parameter #0). While the ‘set in progress’ state is active, the BMC 
will return data from this copy of the parameters, plus any uncommitted 
changes that were made to the data. Otherwise, the BMC returns parameter 
data from non-volatile storage. 


Table 23-, LAN Configuration Parameters 


Parameter 


Set In Progress 
(volatile) 


# 
0 


Parameter Data (non-volatile unless otherwise noted)! 


data 1 This parameter is used to indicate when any of the following parameters are being 
updated, and when the updates are completed. The bit is primarily provided to alert software 
than some other software or utility is in the process of making changes to the data. 
An implementation can also elect to provide a ‘rollback’ feature that uses this information to 
decide whether to ‘roll back’ to the previous configuration information, or to accept the 
configuration change. 
If used, the roll back shall restore all parameters to their previous state. Otherwise, the 
change shall take effect when the write occurs. 
[7:2] - reserved 
[1:0] - 00b = set complete. If a system reset or transition to powered down state occurs 
while ‘set in progress’ is active, the BMC will go to the ‘set complete’ state. If 
rollback is implemented, going directly to ‘set complete’ without first doing a 
‘commit write’ will cause any pending write data to be discarded. 
01b = set in progress. This flag indicates that some utility or other software is 
presently doing writes to parameter data. It is a notification flag only, it is not a 
resource lock. The BMC does not provide any interlock mechanism that would 
prevent other software from writing parameter data while. 
10b = commit write (optional). This is only used if a rollback is implemented. The 
BMC will save the data that has been written since the last time the ‘set in 
progress’ and then go to the ‘set in progress’ state. An error completion code 
will be returned if this option is not supported. 
11b = reserved 
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Parameter 


Parameter Data (non-volatile unless otherwise noted)" 


Authentication Type 
Support (Read Only) 


This ‘read only’ field returns which possible Authentication Types (algorithms) can be 
enabled for the given channel. The following Authentication Type Enables parameter selects 
which Authentication Types are available when activating a session for a particular 
maximum privilege level. 


[7:6] - reserved 
[5:0] - Authentication type(s) enabled for this channel (bitfield): 
All bits: 1b = supported 
Ob = authentication type not available for use. 
[5] - OEM proprietary (per OEM identified by the IANA OEM ID in the RMCP Ping 
Response) 
[4] - straight password / key 
[3] - reserved 
[ 


2]- MD5 
DI. MD2 
[0] - none 


Authentication Type 
Enables 


This field is used to configure which Authentication Types are available for use when a 
remote console activates an IPMI messaging connection to the BMC for a given requested 
maximum privilege level. Once the session has been activated, the accepted authentication 
type will be the only one used for authenticated packets, regardless of the present operating 
privilege level, or the privilege level associated with the command. 


Depending on configuration of per-message and user-level authentication disables, 
unauthenticated packets (authentication type = none) may also be accepted. The BMC 
makes no attempt to check or ensure that stricter authentication types are associated with 
higher requested maximum privilege levels. E.g. it is possible to configure the BMC so 
activating a session with a maximum privilege level of ‘User’ requires MD5 while ‘Admin’ 
requires ‘none’. 


Note: An implementation that has fixed privilege and authentication type assignments, in 
which case this parameter can be implemented as Read Only. It is recommended that an 
implementation that implements a subset of the possible authentication types returns a CCh 
error completion code if an attempt is made to select an unsupported authentication type. 
byte 1: Authentication Types returned for maximum requested privilege = Callback level. 
[7:6] - reserved 
[5:0] - Authentication type(s) enabled for this channel (bitfield): 
All bits: 1b = authentication type enabled for use at given privilege level 
Ob = authentication type not available for use at given privilege level. 
[5] - OEM proprietary (per OEM identified by the IANA OEM ID in the RMCP Ping 
Response) 
[4] - straight password / key 
[3] - reserved 
[2]- MD5 
[1]- MD2 
[0] - none 


byte 2: Authentication Type(s) for maximum privilege = User level 
(format follows byte 1) 


byte 3: Authentication Type (s) for maximum privilege = Operator level 
(format follows byte 1) 


byte 4: Authentication Type (s) for maximum privilege = Administrator level 
(format follows byte 1) 


byte 5: Authentication Type (s) for maximum privilege = OEM level 
(format follows byte 1) 


IP Address 


data 1:4 - IP Address 
MS-byte first. 
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Parameter # | Parameter Data (non-volatile unless otherwise noted)!" 
IP Address Source 4 data 1 
[7:4] - reserved 
[3:0] -address source 
Oh = unspecified 
1h = static address (manually configured) 
2h = address obtained by BMC running DHCP 
3h = address loaded by BIOS or system software 
4h = address obtained by BMC running other address assignment protocol 
MAC Address 5 data 1:6 - MAC Address for messages transmitted from BMC. 
(can be Read Only) MS-byte first. An implementation can either allow this parameter to be settable, or it can be 
implemented as Read Only. 
Subnet Mask 6 data 1:4 - Subnet Mask. MS-byte first. 
IPv4 Header 7 data 1 - Time-to-live. 1-based. (Default = 40h) 
Parameters Value for time-to-live parameter in IP Header for RMCP packets and PET Traps 
transmitted from this channel. 
data 2 
[7:5] - Flags. Sets value of bit 1 in the Flags field in the IP Header for packets transmitted 
by this channel. (Default = 010b “don’t fragment”) 
[4:0] - reserved 
data 3 
[7:5] - Precedence (Default = 000b) 
[4:1] - Type of Service (Default = 1000b, “minimize delay”) 
[0] - reserved 
Primary RMCP Port 8 data 1:2 - Primary RMCP Port Number, LSByte first. 
Number (optional) Default = 26Fh (RMCP ‘Aux Bus Shunt' port) 
Secondary RMCP Port 9 data 1:2 - Secondary Port Number, LSByte first. 
Number (optional) Default = 298h (RMCP ‘Secure Aux Bus’ port) 
BMC-generated ARP 10 data 1 - BMC-generated ARP control. Note: the individual capabilities for BMC-generated 
control ARP responses and BMC-generated Gratuitous ARPs are individually optional. The BMC 
(optional!) should return an error completion code if an attempt is made to enable an unsupported 
capability. 
[7:2] - reserved 
[1] - 1b = enable BMC-generated ARP responses 
Ob = disable BMC-generated ARP responses 
[0] - 1b = enable BMC-generated Gratuitous ARPs 
Ob = disable BMC-generated Gratuitous ARPs 
Gratuitous ARP 11 | data 1 - Gratuitous ARP interval 
interval (optional) Gratuitous ARP interval in 500 millisecond increments. 0-based. 
Interval accuracy is +/- 10%. 
If this configuration parameter is not implemented, gratuitous ARPs shall be issued at a 
rate of once every 2 seconds. 
Default Gateway 12 | data 1:4 - IP Address 
Address MS-byte first. This is the address of the gateway (router) used when the BMC sends a 
message or alert to a party on a different subnet than the one the BMC is on. 
Default Gateway MAC 13 | data 1:6 - MAC Address. MS-byte first. 
Address 
Backup Gateway 14 | data 1:4 - IP Address 
Address MS-byte first. This is the address of an alternate gateway (router) that can be selected 
when a sending a LAN Alert. 
Backup Gateway MAC 15 | data 1:6 - MAC Address. MS-byte first. 
Address 
Community String 16 | data 1:18 - Community String 


Default = ‘public’. Used to fill in the ‘Community String’ field in a PET Trap. This string may 
optionally be used to hold a vendor-specific string that is used to provide the network name 
identity of the system that generated the event. Printable ASCII string-. If a full 18 non-null 
characters are provided, the last character does not need to be a null. 18 characters must 
be written when setting this parameter, and 18 will be returned when this parameter is read. 
The null character, and any following characters, will be ignored when the Community String 
parameter is placed into the PET. The BMC will return whatever characters were written. Le 
it will not set bytes following the null to any particular value. 
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Parameter Data (non-volatile unless otherwise noted)" 


Number of Destinations 
(Read Only) 


data 1 - Number of LAN Alert Destinations supported on this channel. (Read Only). At least 
one set of non-volatile destination information is required if LAN alerting is supported. 
Additional non-volatile destination parameters can optionally be provided for supporting an 
alert ‘call down’ list policy. A maximum of fifteen (1h to Fh) non-volatile destinations are 
supported in this specification. Destination 0 is always present as a volatile destination that 
is used with the Alert Immediate command. 

[7:4]- reserved. 


[3:0]- Number LAN Destinations. A count of 0h indicates LAN Alerting is not supported. 


Destination Type 
(volatile / non-volatile - 
see description) 


18 


Sets the type of LAN Alert associated with the given destination. This parameter is not 
present if the Number of Destinations parameter is 0. 

data 1 - Set Selector = Destination selector, 0 based. 

[7:4] -reserved 


[3:0] - Destination selector. Destination 0 is always present as a volatile destination that is 
used with the Alert Immediate command. 


data 2 - Destination Type 
[7] - Alert Acknowledge. 
Ob = Unacknowledged. Alert is assumed successful if transmission occurs 
without error. This value is also used with Callback numbers. 
1b= Acknowledged. Alert is assumed successful only if acknowledged is 
returned. Note, some alert types, such as Dial Page, do not support an 
acknowledge. 
[6:3] - reserved 
[2:0] - Destination Type 


000b = PET Trap destination 
001b -101b = reserved 

110b = OEM 1 

111b = OEM 2 


data 3 - Alert Acknowledge Timeout / Retry Interval, in seconds, 0-based (i.e. minimum 
timeout = 1 second). 


This value sets the timeout waiting for an acknowledge, or the time between 
automatic retries depending on whether the alert is acknowledge or not. 
Recommended factory default = 3 seconds. Value is ignored if alert type does not 
support acknowledge, or if the Alert Acknowledge bit (above) is Ob. 


data 4 - Retries 

[7:4]- reserved 

[3] - reserved 

[2:0]- Number of times to retry alert to given destination. 0 = no retries (alert is only sent 
once). If the alert is acknowledged (Alert Acknowlege bit = 1b) the alert will only be 
retried if a timeout occurs waiting for the acknowledge. Otherwise, this value 
selects the number of times an unacknowledged alert will be sent out. The timeout 
interval or time between retries is set by the Alert Acknowledge Timeout / Retry 
Interval value (byte 3 of this parameter). 
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Parameter # Parameter Data (non-volatile unless otherwise noted)" 

Destination Addresses 19 Sets/Gets the list of IP addresses that a LAN alert can be sent to. This parameter is not 
present if the Number of Destinations parameter is 0. 

data 1 - Set Selector = Destination Selector. 

[7:4] - reserved 

[3:0] - Destination selector. Destination 0 is always present as a volatile destination that is 
used with the Alert Immediate command. 


data 2 - Address Format 

[7:4] - Address Format. 
Oh = IPv4 IP Address followed by DIX Ethernet/802.3 MAC Address 
1h = IPv6 IP Address 

[3:0] - reserved 


For Address Format = Oh: 

data 3 - Gateway selector 

[7:1] - reserved 

[0] - Ob = use default gateway first, then backup gateway (Note: older 
implementations (errata 4 or earlier) may only send to the default gateway.) 
1b = use backup gateway 


data 4:7 - Alerting IP Address (MS-byte first) 
data 8:13 - Alerting MAC Address (MS-byte first) 


For Address Format = 1h: 

data 3:18 - Alerting IPv6 Address (MS-byte first) 

(Router MAC Address is obtained through Neighbor Discovery or using the addressing 
specified using static router configuration in the LAN Configuration Parameters) 


Following parameters are introduced with IPMI v2.0 / RMCP+ 
VLAN configuration can be used with IPMI v1.5 and IPMI v2.0sessions. Parameters labeled “RMCP+” are specific to 
IPMI v2.0 implementations that implement IPMI v2.0 / RMCP+ sessions. 
802.1q VLAN ID (12-bit) data 1 
[7:0] - Least significant 8-bits of the VLAN ID. 00h if VLAN ID not used. 
data 2 
[7]- | VLAN ID enable. 


Ob = disabled, 1b = enabled. If enabled, the BMC will only accept packets for this 
channel if they have 802.1q fields and their VLAN ID matches the VLAN ID value 
given in this parameter. 


reserved 
most significant four bits of the VLAN ID 


802.1q VLAN Priority 


reserved 


Value for Priority field of 802.1q fields. Ignored when VLAN ID enable is Ob 
(disabled) - See 802. 1q VLAN ID parameter, above. Setting is network dependent. 
By default, this should be set to OOOb. 


RMCP+ Messaging 22 This parameter provides a count of the number (16 max.) of Cipher Suites available to be 
Cipher Suite Entry enabled for use with IPMI Messaging on the given channel. 

Support 

(Read Only) Software can find out what security algorithms are associated with given Cipher Suite ID by 


using the Get Channel Cipher Suites command. In addition, there are Cipher Suite IDs 
assigned for standard Cipher Suites (see Table 22-, Cipher Suite IDs) 


data 1 
[7:5] - reserved 
[4:0] - Cipher Suite Entry count. Number of Cipher Suite entries, 1-based, 10h max. 
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RMCP+ Messaging 23 This parameter contains zero to sixteen (16) bytes of Cipher Suite IDs for Cipher Suites that 
Cipher Suite Entries can be used for establishing an IPMI messaging session with the BMC. The number of 
(Read Only) Cipher Suites that are supported is given in the preceding parameter. 
data 1 - Reserved 
data 2 - Cipher Suite ID entry A. 
data 3 - Cipher Suite ID entry B. 
data 17 - Cipher Suite ID entry P. 
RMCP+ Messaging 24 This parameter allows the configuration of which privilege levels are associated with each 
Cipher Suite Privilege Cipher Suite. The total number of nibbles supported (zero to sixteen) matches the number of 
Levels fixed Cipher Suite IDs. 
data 1 - Reserved 
data 2 - Maximum Privilege Level for 1st and 2nd Cipher Suites 
[7:4]- Maximum Privilege Level for 2nd Cipher Suite 
[3:0] - Maximum Privilege Level for 1st Cipher Suite 
Oh = Unspecified (given Cipher Suite is unused) 
1h = Callback level 
2h = User level 
3h = Operator level 
4h = Administrator level 
5h = OEM Proprietary level 
data 3 - Maximum Privilege Level for 3rd and 4th Cipher Suites 
data 4 - Maximum Privilege Level for 5th and 6th Cipher Suites 
data 9 - Maximum Privilege Level for 15th and 16th Cipher Suites 
Destination Address 25 Sets/Gets the VLAN IDs (if any) addresses that a LAN alert can be sent to. This parameter 


VLAN TAGs 
(can be READ ONLY, 
see description) 


is not present if the Number of Destinations parameter is 0, or if the implementation does 
not support the use of VLAN IDs for alerts. Otherwise, the number of VLAN TAG entries 
matches the number of Alert Destinations. 


An implementation may only be able to send alerts using the same VLAN TAG configuration 
as specified by parameters 20 and 21, in which case this parameter is allowed to be READ 
ONLY, where data 3-4 reflects the settings of parameters 20 and 21, and data 2 [7:4] 
indicates that VLAN TAGs are being used for alerts. If the implementation does support 
configurable VLAN TAGs for alert destinations, it must support configuring unique TAG 
information for all destinations on the given channel. 


data 1 Get Selector = Destination Selector. 

[7:4] -reserved 

[3:0] - Destination selector. Destination 0 is always present as a volatile destination that is 
used with the Alert Immediate command. 


data 2 - Address Format 

[7:4] - Address Format. 
Oh = VLAN ID not used with this destination 
1h = 802.1q VLAN TAG 

[3:0] - reserved 


For Address Format = th: 
data 3-4 - VLAN TAG 
[7:0]- VLAN ID, least-significant byte 
[11:8] - VLAN ID, most-significant nibble 
[12] - CFI (Canonical Format Indicator. Set to Ob) 
[15:13] - User priority (000b, typical) 
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Bad Password 
Threshold (optional) 


26 


Sets/Gets the Bad Password Threshold. If implemented and non-zero, this value determines 
the number of sequential bad passwords that will be allowed to be entered for the identified 
user before the user is automatically disabled from access on the channel. 

For example, a value of 3 indicates that 3 sequential attempts are allowed for the given 
username on the particular channel. If the password for the third attempt is not correct, the 
user will be disabled for the channel. If this value is zero (00h) then there is no limit on bad 
passwords. 


The effect of the disable is the same as if a Set User Access command were used to 
remove the user's access from the channel. 


Bad password attempts are tracked according to individual username on a per channel 
basis. (Thus, a given username may be disabled on one channel, but still enabled on 
another) Bad password attempts are not counted if integrity check or other session 
parameters, such as session ID, sequence number, etc. are invalid. That is, bad password 
attempts are not counted if there are any other errors that would have caused the login 
attempt to be rejected even if the password was valid. The count of bad password attempts 


is retained as long as the BMC remains powered and is not reinitialized. 


Counting automatically starts over (is reset) under any one of the following conditions: 
a) a valid password is received on any of the allowed attempts 

b) the Attempt Count Reset Interval expires 

c) the user is re-enabled using the Set User Access command 

d) the user is automatically re-enabled when the User Lockout Interval expires. 

e) the Bad Threshold number parameter value is re-written or changed 


The Set User Access command is used to re-enable the user for the Channel. 
data 1 

7:1]- reserved 

0] -Ob = do not generate an event message when the user is disabled. 


1b = generate a Session Audit sensor "Invalid password disable" event message. 
data 2 
7:0 - Bad Password Threshold number. 


data 3:4 


15:0 - Attempt Count Reset Interval. The interval, in tens of seconds, for which the 
accumulated count of bad password attempts is retained before being 
automatically reset to zero. The interval starts with the most recent bad password 
attempt for the given username on the channel. This interval is allowed to reset if 
a BMC power cycles or re-initialization occurs while the interval is being counted. 
0000h = Attempt Count Reset Interval is disabled. The count of bad password 


attempts is retained as long as the BMC remains powered and is not 
reinitialized. 


data 5:6 
15:0 - User Lockout Interval. The interval, in tens of seconds, that the user will remain 


disabled after being disabled because the Bad Password Threshold number was 
reached. The user is automatically re-enabled when the interval expires. Note that 


this requires the BMC implementation to track that the user was disabled because 
of a Bad Password Threshold. This interval is allowed to be restarted if a BMC 
power cycle or re-initialization occurs while the interval is being counted. Note that 
this requires an internal non-volatile setting to be maintained that tracks when a 
particular user has been temporarily disabled due to the Bad Password 
Threshold. This is required to distinguish a user that was disabled automatically 
from a user that is intentionally disabled using the Set User Access command. 
0000h = User Lockout Interval is disabled. If a user was automatically disabled 
due to the Bad Password threshold, the user will remain disabled until 
re-enabled via the Set User Access command. 
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IPv6/IPv4 Support 50 This parameter is Mandatory if IPv6 addressing is supported. This parameter and the 
(read only) following parameters, up to and including the “IPv6 Neighbor Discovery I SLAAC Timing 
Configuration” parameter should not be supported if the implementation does not support 
IPv6 addressing per this specification. 
data 1 — 
[2] -1b = Implementation supports IPv6 Destination Addresses for LAN Alerting. 
[1] -1b = Implementation can be configured to use both IPv4 and IPv6 addresses 
simultaneously. 
[0] -1b = Implementation can be configured to use IPv6 addresses only. 
IPv6/IPv4 Addressing 51 This parameter is Mandatory if IPv6 addressing is supported. 
enables 
data 1 — 
The following values can be set according the capabilities specified in parameter 50. 
00h = IPv6 addressing disabled. 
01h = Enable IPv6 addressing only. IPv4 addressing is disabled. 
02h = Enable IPv6 and IPv4 addressing simultaneously. 
IPv6 Header Static 52 This parameter is Mandatory if IPv6 addressing is supported. Recommended Default = 0. 
Traffic Class 
data 1 — Traffic Class 
This field determines the Traffic Class used by the BMC when transmitting Alert packets 
using IPv6 addressing. Otherwise, the BMC uses the traffic class value from the remote 
console. Refer to [RFC2460] and [RFC2474] for additional information. 
IPv6 Header Static Hop 53 This parameter is Mandatory if IPv6 addressing is supported. Default = 64. 
Limit 
data 1 — Static Hop Limit 
This parameter is used under two circumstances: 
1. If the router returns ‘unspecified’ (00h) as the hop limit. 
2. When a static router configuration is used, the BMC does not pay attention to the 
Router Advertisement messages and uses this value for the Hop Limit instead. 
IPv6 Header Flow Label | 54 data 1:3 — Flow Label, 20-bits, right justified, MS Byte first. Default = 0. 
[OPTIONAL] If this configuration parameter is not supported, the Flow Label shall be set to 0 per 
[RFC2460]. Bits [23:20] = reserved — set to Ob. 
IPv6 Status (read only) 55 Provides the number of IPv6 addresses that are supported and configurable for use by the 


BMC for IPMI. 
This parameter is Mandatory if IPv6 addressing is supported. 


data 1: - Static address max 

Maximum number of static IPv6 addresses for establishing connections to the BMC. Note: in 
some implementations this may exceed the number of simultaneous sessions supported on 
the channel. 0 indicates that static address configuration is not available. 


data 2: - Dynamic address max 

Maximum number of Dynamic (SLAAC/ DHCPv6) IPv6 addresses that can be obtained for 
establishing connections to the BMC. Note: in some implementations this may exceed the 
number of simultaneous sessions supported on the channel. 0 = Dynamic addressing is not 
supported by the BMC. 


data 3: - 

[7:2]- reserved 

[1] -1b = SLAAC addressing is supported by the BMC 

[0] - 1b = DHCPv6 addressing is supported by the BMC (optional) 
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IPv6 Static Addresses 


56 


This parameter is Mandatory if IPv6 addressing is supported. 


data 1  - Set Selector = Address selector, 0 based. 

BMC shall provide at least one IPv6 Static Address entry if static address configuration is 
supported. For the case of 0 Static addresses, only selector 0 is allowed, data[2:20] are 
reserved, data 21 = “disabled”. 


data2 - Address source/type 
[7]- enable=1/disable=0 
[6:4] - reserved 
[3:0]- source/type 
Oh = Static 
All other = reserved 


data 3-19 - IPv6 Address, MS-byte first. 
data 20 - Address Prefix Length 


data 21 - Address Status (Read-only parameter) 
00h = Active (in-use) 
01h = Disabled 
02h = Pending (currently undergoing DAD [duplicate address detection], optional) 
03h = Failed (duplicate address found, optional) 
04h = Deprecated (preferred timer has expired, optional) 
05h = Invalid (validity timer has expired, optional) 
All other = reserved 


IPv6 DHCPV6 Static 
DUID storage length 
(read only) 


57 


This parameter is Mandatory if IPv6 addressing is supported. 


data 1 — The maximum number of 16-byte blocks that can be used for storing each DUID via 


the IPv6 DHCPv6 Static DUIDs parameter. 1-based. Returns 0 if IPv6 Static Address 
configuration is not supported. 


Per [RFC3315] the DUID can be up to 128 octets long — though most forms are significantly 


shorter. As of this writing, DUID Type 2 (Vendor-assigned unique ID based on Enterprise 
Number) is the format which has a vendor-specific length and could be lengthy. It is 
recommended that the implementation supports at least 3 blocks per DUID. 
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IPv6 DHCPv6 Static 
DUIDs 


58 


DUIDs (DHCP Unique Identifiers). Per [RFC3315], each DHCP client and server has a 
DUID. This parameter provides storage for each DUID that identifies a particular IPv6 
Interface Association (IA). 


This parameter is Mandatory if IPv6 addressing is supported. 


data 1  - Set Selector = DUID selector, 0 based. Each set selector matches with the 
corresponding Set Selector for the IPv6 Static Addresses parameter. 

This parameter is Mandatory if IPv6 addressing is supported. If IPv6 Static Address 
configuration is not supported, only selector 0 and block 0 is allowed and nothing is returned 
for data 3-18. 


data 2 - Block Selector, 0-based 
Selects which 16-byte block of DUID data to write for the DUID storage from the given Set 
Selector. 


data 3-18 - DUID data for given block. The first byte of block 0 is the overall length of the 
following DUID data (1-based). The remaining DUID data is formatted and stored in network 
byte order (MS-bytes first) per [RFC3315], starting with the DUID Type field. 


Notes: Per [RFC3315]: “A client must associate at least one distinct IA with each of its 
network interfaces for which it is to request the assignment of IPv6 addresses from a DHCP 
server. The client uses the IAs assigned to an interface to obtain configuration information 
from a server for that interface. Each IA must be associated with exactly one interface.” 


Consequently, the Set Selector for the DUID effectively becomes bound to a particular IA, 
and since the Set Selector for the DUID and the Set Selector for the IPv6 Address 
correspond to one another, the Set Selector for the IPv6 address is also associated with the 
IA. In effect, the Set Selector value becomes the handle for a particular IA. 


Depending on DUID Type, a given MAC address MAY have more than one DUID (and IPv6 
Address) associated with it. The Type 3 DUID just uses the link layer address directly (MAC 
address) and therefore would not support more than one DUID for the MAC address. Other 
DUID Types do not have that restriction. 


IPv6 Dynamic (SLAAC/ 
DHCPv6) Address 


(read only) 
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This parameter is Mandatory if IPv6 addressing is supported. 


data 1 -Set Selector = Address selector, 0 based. 

BMC shall provide at least one entry in the array. For the case of 0 SLAAC and DHCPv6 
addresses, only selector 0 is allowed, data[2:20] are reserved, data 21 = “disabled”. 
Mandatory if IPv6 addressing is supported. 


data2 - Address source/type 
[7:4] - reserved 
[3:0]- source/type 
0 — Reserved 
1 — SLAAG (StateLess Address Auto Configuration) 
2 — DHCPvé6 (optional) 
Other - reserved 


data 3-19 - IPv6 Address, MS-byte first. 
data 20 - Address Prefix Length 


data 21 - Address Status 

0 — Active (in-use) 
1 — Disabled 
2 — Pending (currently undergoing DAD, optional) 
3 — Failed (duplicate address found, optional) 
4 — Deprecated (preferred timer has expired, optional) 
5 — Invalid (validity timer has expired, optional) 

other — reserved 
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IPv6 DHCPv6 Dynamic 
DUID storage length 
(read only) 


60 


This parameter is Mandatory if IPv6 addressing is supported. 


data 1 — The maximum number of 16-byte blocks that can be used for storing each DUID via 
the IPv6 DHCPv6 Static DUIDs parameter. 1-based. Returns 0 if IPv6 Static Address 
configuration is not supported. 


Per [RFC3315] the DUID can be up to 128 octets long — though most forms are significantly 
shorter. As of this writing, DUID Type 2 (Vendor-assigned unique ID based on Enterprise 
Number) is the format which has a vendor-specific length and could be lengthy It is 
recommended that the implementation supports at least 3 blocks per DUID. 


IPv6 DHCPv6 Dynamic 
DUIDs 


61 


This parameter is Mandatory if IPv6 addressing is supported. 


DUIDs (DHCP Unique Identifiers). Per [RFC3315], each DHCP client and server has a 
DUID. Although DHCPVé6 is not used for address assignment when IPv6 static addresses 
are enabled, DHCPv6 may be used for discovery, configuration, or other purposes. 
Therefore, this configuration parameter provides a mechanism for setting and returning a 
DUID that is associated with each IPv6 Static Address that is supported. The Set Selector 
for the Dynamic DUIDs Type parameter matches the set selector for the corresponding IPv6 
Static address. . If IPv6 Dynamic Address configuration is not supported, only selector 0 and 
block 0 is allowed and nothing is returned for data 3-18. 


data 1 -Set Selector = DUID selector, 0 based. 

Each set selector matches with the corresponding Set Selector for the IPv6 Dynamic 
Addresses parameter. 

This parameter is Mandatory if IPv6 addressing is supported. If IPv6 Dynamic Address 
configuration is not supported, only selector 0 is allowed and the type shall be returned as 
‘0’ (not supported). 


data2 - Block Selector (0-based) 
Selects which 16-byte block of DUID data to write for the DUID storage from the given Set 
Selector. 


data 3-18 - DUID data for given block. The first byte of block 0 is the overall length of the 
following DUID data (1-based). The remaining DUID data is formatted and stored in network 
byte order (MS-bytes first) per [RFC3315], starting with the DUID Type field. 


Notes: Refer to the notes for the IPv6 DHCPv6 Static DUIDs parameter, above, for more 
information. 


IPv6 DHCPv6 Timing 
Configuration Support 
(read only) 


62 


This parameter is Mandatory if IPv6 addressing is supported. 


data1 
[7:2] - reserved 
[1:0]- 00b= DHCPv6 timing configuration per IPMI is not supported. 
01b = ‘Global’ - Timing configuration applies across all interfaces (IAs) that use 
dynamic addressing and have DHCPVv6 is enabled. 
10b = ‘Per interface’ - Timing is configurable for each interface and used when 
DHCPV6 is enabled for the given interface (IA). 
11b= reserved 
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IPv6 DHCPv6 Timing & 
Configuration 

(optional, 
recommended) 


63 


This parameter is Mandatory if DHCPv6 timing configuration is supported as indicated by 
the IPv6 DHCPv6 Timing Configuration Support parameter, above. 


If DHCPv6 Dynamic Address configuration is not supported, this parameter should not be 
implemented. 


This parameter is used to configure the default timing values for DHCPv6. These values are 
used when the BMC is initially powered up or reinitialized, and after DHCPv6 address 
configuration becomes enabled or is re-enabled. Note that some of these parameters may 
be superseded by values received from the DHCP server. See Section 23.2a, DHCPv6 
Timing Parameters, for more information. 


The DHCPv6 Timing configuration can be ‘global’, where a single set of timing parameters 
applies to all DHCPv6 transactions for all supported interfaces on the channel that are using 
DCHPvé6 for IPv6 address assignment on the channel or ‘per interface’ in which case only 
one set of timing parameters needs to be supported. The IPv6 DHCPv6 Timing 
Configuration Support parameter lets software know what is supported by the 
implementation. 


data 1 - Set Selector = IPv6 interface (IA) selector, 0 based. 
If ‘global’ the Set Selector is always 0. If ‘per interface’, each set selector matches with the 
corresponding Set Selector for the IPv6 Dynamic Addresses parameter. 


data 2 - Block Selector (0-based) 

Selects which 16-byte block of timing parameter data is accessed for the given Set Selector. 
See Table 23-4a, DHCPv6 Timing Parameters, for the specification of the data content in 
each block. 


IPv6 Router Address 
Configuration Control 
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This parameter is Mandatory if IPv6 addressing is supported. 


Router discovery is part of support for SLAAC and DHCPv6 addressing (dynamic 
addressing). This parameter controls whether automated router discovery occurs when 
static addresses are used for the BMC. It also enables the use of static router addresses. 


data 1 — 

[7:2] - reserved 

[1]- 1b= enable dynamic router address configuration via router advertisement 
messages. Router solicitation messages are sent with timing and behavior as 
specified in [RFC4861]. The router solicitation timing values from the IPv6 
Neighbor Discovery / SLAAC Timing Configuration parameter (below) are 
used if that parameter is implemented. 

[0]- 1b= enable static router address. If static and dynamic router addressing are 
enabled, the BMC shall attempt to use the static router address and prefix 
first. 


IPv6 Static Router 1 IP 
Address 
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This parameter is Mandatory if IPv6 addressing is supported. 


data 1:16 - IPv6 Router IP Address (Used when static address is selected in the IPv6 IP 
Address Source configuration parameter). 
16 bytes of IPv6 address, MS-byte first. 


IPv6 Static Router 1 
MAC Address 
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This parameter is Mandatory if IPv6 addressing is supported. 


data 1:6 — Router MAC Address. MS-byte first. 


IPv6 Static Router 1 
Prefix Length 


67 


This parameter is Mandatory if IPv6 addressing is supported. 


data 1 — Prefix length. Only used with static addressing. Used to determine whether an 
address is ‘on link’ (can be accessed directly) or ‘off link’ (must go to the 
corresponding Static Gateway address). The upper bits of the first address entry 
in the IPv6 Static Addresses parameter are used for the prefix value. 
Prefix length should be from 0 to 128 as per [RFC4861]. 


IPv6 Static Router 1 
Prefix Value 


68 


This parameter is Mandatory if IPv6 addressing is supported 


datai- set selector (0-based) 
data 2:17 — Prefix value. MS-byte first. 
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IPV6 Static Router 2 IP 68 This parameter is Mandatory if IPv6 addressing is supported. 
Address 
data 1:16 - IPv6 Gateway IP Address (Used when static address is selected in the IPv6 IP 
Address Source configuration parameter). 
16 bytes of valid IPv6 address, MS-byte first. 
data 1-16 - Static Default Gateway address, MS-byte first. 
IPV6 Static Router 2 69 This parameter is Mandatory if IPv6 addressing is supported. 
MAC Address 
data 1:6 - MAC Address. MS-byte first. 
IPV6 Static Router 2 70 This parameter is Mandatory if IPv6 addressing is supported. 
Prefix Length 
data 1 — Prefix length. Only used with static addressing. Used to determine whether an 
address is ‘on link’ (can be accessed directly) or ‘off link’ (must go to the 
corresponding Static Gateway address). The upper bits of the first address entry 
in the IPv6 Static Addresses parameter are used for the prefix value. 
Prefix length should be from 0 to 128 as per [RFC4861]. 
IPv6 Static Router 2 71 This parameter is Mandatory if IPv6 addressing is supported. 


Prefix Value 


data1- set selector (0-based) 
data 2:17 — Prefix value. MS-byte first. 


The following “Dynamic Router Info” parameters are informational and may be used to by software to 
monitor whether the BMC is receiving router advertisements, and if so, the most recent router address 
and prefix information it has received. 


Number of Dynamic 
Router Info Sets 
(read-only) 


72 


This parameter is Mandatory if IPv6 dynamic addressing is supported. 


data1- Number of dynamic Router Address information entries. If a router returns multiple 
prefixes, there will be a one set of entries (prefix, router ip adddress, and router 
mac address) for each prefix. Entries are handled in a FIFO manner. That is, 
once all entries are used, the BMC replaces older sets with newer ones in the 
order that they are received if the new information doesn’t match an entry that’s 
already on the list. 


Set to 0 if dynamic Router Address information entries are not supported. 
Otherwise, the required minimum = 2. 


Recommended: 4 entries, min. This allows the BMC to track two router 
addresses and two prefixes per router address. 


Note that per [RFC4861] “a host MUST retain at least two router addresses and 
SHOULD retain more.” The implementation should provide one info set for each 
router address + prefix it supports. 


IPv6 Dynamic Router 
Info IP Address 
(read-only) 


73 


This parameter is Mandatory if Number of Dynamic Router Info Sets is non-zero. 


data1 - set selector (0-based) 
data 2:17- IPv6 Router IP Address (Used when static address is selected in the IPv6 IP 
Address Source configuration parameter). 

16 bytes of valid IPv6 address, MS-byte first. Set to 0000 0000h if the corresponding 
IPv6 Dynamic Router Info Prefix Length = FFh. 


IPv6 Dynamic Router 
Info MAC Address 
(read-only) 


74 


This parameter is Mandatory if Number of Dynamic Router Info Sets is non-zero. 


data 1 - set selector (0-based) 
data 1:6 - MAC Address. MS-byte first. 
Set to 00_0000h if the corresponding IPv6 Dynamic Router Info Prefix Length = FFh. 
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Parameter # Parameter Data (non-volatile unless otherwise noted)!" 

IPv6 Dynamic Router 75 This parameter is Mandatory if Number of Dynamic Router Info Sets is non-zero. 

Info Prefix Length 

(read-only) data1 - set selector (0-based) 
data 2 — Prefix length. Used with dynamic router address configuration. Used to determine 
whether an address is ‘on link’ (can be accessed directly) or ‘off link’ (must go to the 
corresponding Dynamic Router address). The upper bits of the first address entry in the 
IPv6 Static Addresses parameter are used for the prefix value. 

Prefix length should be from 0 to 128 as per [RFC4861]. 
FFh = Dynamic address is unspecified. The corresponding IPv6 Dynamic Router Info IP 
Address and MAC Address fields should be ignored. 

IPv6 Dynamic Router 76 This parameter is Mandatory if Number of Dynamic Router Info Sets is non-zero. 

Info Prefix Value 

(read-only) datai- set selector (0-based) 
data 2:17 — Prefix value. Set to all Os if the corresponding IPv6 Dynamic Router Info Prefix 
Length = FFh. 

IPv6 Dynamic Router Zë This parameter is optional (recommended). 

Received Hop Limit 

[optional, This value is obtained from the router as part of a Router Advertisement message. The BMC 

recommended] returns the most recently received information that it has received, regardless of the router 
that sent the advertisement. 

IPv6 Neighbor 78 This parameter is Mandatory if IPv6 static router address configuration is supported. 

Discovery / SLAAC 

Timing Configuration datat: 

Support [7:2] - reserved Mm 
[1:0] - 00b = IPv6 Neighbor Discovery / SLAAC timing configuration per IPMI is not 

(read only) supported. 

01b = ‘Global’ - Timing configuration applies across all interfaces (IAs) that have 
IPv6 dynamic addressing enabled. 

10b = ‘Per interface’ - Timing is configurable for each interface and used when 
IPv6 dynamic addressing is enabled for the given interface (IA). 

11b = reserved 

IPv6 Neighbor 79 This parameter is Mandatory if Neighbor Discovery / SLAAC Timing configuration is 

Discovery / SLAAC supported. If it is not supported, this parameter is not implemented. \ 

Timing Configuration This parameter is used to configure the default timing values for IPv6 Neighbor Discovery / 
SLAAC. These values are used when the BMC is initially powered up or reinitialized, and 
after IPv6 dynamic addressing becomes enabled or is re-enabled for the interface(s). Note 
that some of these parameters may be superseded by values received from the router. See 
Section 23.2b, Neighbor Discovery / SLAAC Timing Parameters, for more information. 
The Neighbor Discovery / SLAAC Timing configuration can be ‘global’, where a single set of 
timing parameters applies to all Neighbor Discovery / SLAAC transactions for all supported 
interfaces on the channel that are using Neighbor Discovery / SLAAC for IPv6 address 
assignment on the channel or ‘per interface’ in which case only one set of timing 
parameters needs to be supported. The IPv6 Neighbor Discovery / SLAAC Timing 
Configuration Support parameter lets software know what is supported by the 
implementation. 
data 1: - Set Selector = IPv6 interface (IA) selector, 0 based. 

If ‘global’ the Set Selector is always 0. If ‘per interface’, each set selector matches with the 
corresponding Set Selector for the IPv6 Dynamic Addresses parameter. 

data 2: - Block Selector (0-based) 

Selects which 16-byte block of timing parameter data is accessed for the given Set Selector. 
See Table 23-4b, Neighbor Discovery / SLAAC Timing Parameters for the specification of 
the data content in each block. 

OEM Parameters 192: | This range is available for special OEM configuration parameters. The OEM is identified 

255 | according to the Manufacturer ID field returned by the Get Device ID command. 


1. Choice of system manufacturing defaults is left to the system manufacturer unless otherwise specified. 

2. This configuration parameter must be supported if the controller autonomously issues gratuitous ARPs or ARP responses. 
This requirement only applies to use of gratuitous ARPs or ARP responses that are being generated to support 
IPMI over LAN communication sessions. It does not apply to LAN communications for features that are outside 
the IPMI specification. Enabling or disabling gratuitous ARPs or ARP responses using this parameter for IPMI 
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does not necessarily affect ARP responses that are being generated by features that are defined outside the 
IPMI specification. 


23.2a DHCPv6 Timing Parameters 


The following table specifies the block selector and offset values for the DHCPv6 timing parameters. Data must 
be provided for all offsets. Unused / unsupported values shall be set to OOh unless otherwise specified. Refer to 
[RFC3315] for the definitions of the timing parameters. 


Note: The default timing values shown are for example only. Please check the latest RFCs for actual values and 
possible updates. 


Table 23-4a, DHCP v6 Timing Parameters 


Parameter Block M/O/R Size Default Granularity | Range 

offset (bytes) 
Block 1: 
SOL_MAX_DELAY 0 M 1 1 sec .5 Sec .5 to 127 secs. 1-based. 
SOL_TIMEOUT 1 M 1 1 sec .5 sec .5 to 127 secs. 1-based. 
SOL MAX RT 2 M 1 120 secs 30 sec 30 to 7650 secs. 1-based. 
REQ_TIMEOUT 3 M 1 1 sec .5 sec .5 to 127 secs. 1-based. 
REQ MAX RT 4 M 1 30 secs .5 Sec 15 to 142 secs. 1-based 
REQ MAX RC 5 M 1 10 1 count 0 to 100 counts. 
CNF_MAX_DELAY 6 M 1 1 sec .5 sec .5 to 127 secs. 1-based. 
CNF_TIMEOUT 7 M 1 1 sec .5 sec .5 to 127 secs. 1-based. 
CNF_MAX_RT 8 M 1 4 secs 1 secs 1 to 127 secs. 1-based. 
CNF_MAX_RD 9 M 1 10 secs 2 secs 2 to 510 secs. 1-based. 
REN_TIMEOUT 10 M 1 10 secs 2 secs 2 to 510 secs. 1-based. 
REN MAX RT 11 M 1 600 secs 10 secs 10 to 2550 secs. 1-based. 
REB TIMEOUT 12 M 1 10 secs 2 secs 2 to 510 secs. 1-based. 
REB MAX RT 13 M 1 600 secs 4 secs 10 to 2550 secs. 1-based. 
INF_MAX_DELAY 14 HI 1 1 sec .5 sec .5 to 127 secs. 1-based. 
INF TIMEOUT 15 RM" 1 1 sec .5 sec .5 to 127 secs. 1-based. 
Block 2: 
INF MAX RT 0 RU) 1 120 secs 30 sec 30 to 7650 secs. 1-based. 
REL_TIMEOUT 1 rel 1 1 sec .5 sec .5 to 127 secs. 1-based. 
REL_MAX_RC 2 pR [2 1 5 1 sec 1 to 255 secs. 1-based. 
DEC_TIMEOUT 3 RBI 1 1 sec .5 sec .5 to 127 secs. 1-based. 
DEC MAX RC 4 RBI 1 5 1 sec 1 to 255 secs. 1-based. 
HOP_COUNT_LIMIT 5 R [4] 1 32 1 count 1 to 255 counts. 1-based. 


[1] 
[2] 


[3] 


[4] 


Recommended if BMC generates Information Request messages from a MAC Address that is associated with IPMI messaging. 
Recommended if BMC generates Release messages from a MAC Address or IPv6 address that is associated with IPMI 
messaging. 

Recommended if BMC generates Decline messages from a MAC Address or IPv6 address that is associated with IPMI 
messaging. 

Recommended if BMC functions as a relay agent at a MAC Address or IPv6 address that is associated with IPMI messaging. 


23.2b Neighbor Discovery / SLAAC Timing Parameters 


The following table presents the parameters and offsets that are used with the “Neighbor Discovery / SLAAC 
Timing Configuration” parameter from the LAN Configuration Parameters. Refer to [RFC4861] and [RFC4862] 
for the definitions of the timing parameters. 


Note: The default timing values shown are for example only. Please check the latest RFCs for actual values and 
possible updates. 
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e IPv6 Node: A device that implements IPv6. 
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e IPv6 Router: A node that forwards IPv6 packets not explicitly addressed to itself. 


e IPv6 Host: Any node that is not a router. 


The IPMI-specified timing parameters cover the BMC as a Node/Host only. They do not cover using the BMC as 


a Router. 


key: M/O/R = Mandatory / Optional / Recommended. 


Table 23-4b, Neighbor Discovery / SLAAC Timing Parameters 


Block Size 

Parameter offset | M/O/R | (bytes) Default Granularity Range 

Block 1: 

Host constants: 

MAX_RTR_SOLICITATION_DELAY 0 M 1 1 second .25 sec .25 to 63.75 secs. 
1-based. 

RTR SOLICITATION INTERVAL 1 M 1 4 seconds .5 sec -5 to 127.5 secs. 
1-based. 

MAX_RTR_SOLICITATIONS 2 M i 3 transmissions | 1 count 1 to 100 counts. 
1-based. 
FFh = unlimited. 

DupAddrDetectTransmitsl?] 3 M 1 1 transmission | 1 count 0 to 100 counts. 
1-based. 

Node constants: 

MAX_MULTICAST_SOLICIT 4 M 1 3 transmissions | 1 count 1 to 100 counts. 
1-based 

MAX_UNICAST_SOLICIT 5 M 1 3 transmissions | 1 count 1 to 100 counts. 
1-based. 

MAX_ANYCAST_DELAY_TIME 6 M 1 1 second .25 sec 0.25 to 63.75 secs. 
1-based. 

MAX_NEIGHBOR_ADVERTISEMENT 7 M 1 3 transmissions | 1 count 1 to 100 counts. 
1-based. 

REACHABLE_TIME 8 Mi 1 30 seconds 2 sec 2 to 510 secs. 
1-based. 

RETRANS_TIMER 9 M 1 1 second .25 sec 0.25 to 63.75 secs. 
1-based. 

DELAY_FIRST_PROBE_TIME 10 M 1 5 seconds .5 sec .5 to 127.5 secs. 
1-based. 

MAX RANDOM FACTOR 11 OI 1 15 125 1.0 to 4.0. 1-based. 

MIN RANDOM FACTOR 12 oa 1 0.5 125 .125 to 1.0. 1-based 


1. This parameter sets the default value for BaseReachableTime (per [RFC4861]). This value will be used after the BMC is reset 
or reinitialized until an updated value is received from a router. Note that this parameter always returns the default setting. It 
does not return the value given by the router. 

2. If supported, both MIN RANDOM FACTOR and MAX RANDOM FACTOR must be implemented. Setting both 
MIN RANDOM FACTOR and MAX RANDOM FACTOR removes any randomization of the associated intervals. 


3. Refer to [RFC4862] 


23.3 Suspend BMC ARPs Command 


This command can be used to suspend BMC-generated Gratuitous ARPs or ARP responses (if implemented and 
enabled) while run-time software is handling them. ARPs will automatically resume and the ARP suspend option 
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will be automatically disabled whenever the watchdog timer stops or when the Set Watchdog Timer command is 
executed. Software must explicitly enable the suspension after starting or re-starting the Watchdog Timer. This is 
to ensure that BMC-generated ARPs will resume if the watchdog expires (indicating that software may no longer 
be handling the ARPs). 


Software can examine the LAN Configuration Parameters for the desired channel to see if Gratuitous ARPs or 
BMC-generated ARP Responses are enabled. 


Table 23-, Suspend BMC ARPs Command 
byte data field 


Request Data [7:4] reserved 
[3:0] Channel number 
[7:2] - reserved 


ARP Response suspend 

[1]- Ob = do not suspend BMC-generated ARP responses while the 
Watchdog Timer is running. 

1b = suspend BMC-generated ARP responses while Watchdog Timer 

is running. This value must be set after the Watchdog has been 
configured using the Set Watchdog Timer command and, if it is 
desired that the suspension of ARPs be continued, must be re- 
written after any subsequent Set Watchdog Timer commands. 


Gratuitous ARP suspend 

[0] - 0b =do not suspend BMC-generated Gratuitous ARPs while the 
Watchdog Timer is running. 

1b = suspend BMC-generated Gratuitous ARPs while the Watchdog 
Timer is running. This value must be set after the Watchdog has 
been configured using the Set Watchdog Timer command and, if it 
is desired that the suspension of ARPs be continued, must be re- 
written after any subsequent Set Watchdog Timer commands. 
Response Data Completion Code 


Present state of ARP suspension: 
[7:2] - reserved 


ARP Response status 
[1]- 1b =BMC-generated ARP Responses are occurring 
Ob = BMC-generated ARP Responses are presently being suspended 
or are disabled. 


Gratuitous ARP Response status 
[0] - 1b =BMC-generated Gratuitous ARPs are occurring 
Ob = BMC-generated Gratuitous ARPs are presently being suspended 
or are disabled. 


23.4 Get IP/UDP/RMCP Statistics Command 


This command is used retrieving information about the IP connections on the given channel. The info is 
cumulative but volatile. I.e. it is not required to keep these statistics across management controller power cycles. It 
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is recommended that this information be kept across system resets and power cycles. The statistics values are 
initialized to 0 unless otherwise noted. 


Table 23-, Get IP/UDP/RMCP Statistics Command 
byte data field 


[3:0] Channel number. 
2 Clear Statistics 
[7:1]- reserved 


[0]- Ob = don't clear statistics 
1b = clear all statistics values to 0 


Response Data Completion Code 


IP Packets Received. All statistics returned by this command are 1-based 
unless otherwise noted. All statistics stop accumulating at FFFFh unless 


otherwise noted. 

Received IP Header Errors 
Received IP Address Errors 
Fragmented IP Packets Received 
IP Packets Transmitted 

UDP Packets Received 

Valid RMCP Packets Received 
UDP Proxy Packets Received 
UDP Proxy Packets dropped 
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24. RMCP+ Support and Payload Commands 


The following sections list the commands associated with discovering, enabling, and activating payloads under IPMI 
v2.0/RMCP+. Also included in this section are updates and additions to IPMI commands to support IPMI v2.0/RMCP+ 
sessions, authentication, and configuration. 


Table 24-, RMCP+ Support and Payload Commands 


| Section 

Command Defined O/M 
Activate Payload 24.1 ol! 
Deactivate Payload 24.2 ol! 
Suspend/Resume Payload Encryption Command 24.3 OB 
Get Payload Activation Status 24.4 ol! 
Get Payload Instance Info 24.5 ol 
Set User Payload Access Command 24.6 ol 
Get User Payload Access Command 24.7 ol! 
Get Channel Payload Support Command 24.8 ol 
Get Channel Payload Version Command 24.9 ol! 
Get Channel OEM Payload Info Command 24.10 ONA 

1. Mandatory if standard payloads other than IPMI Messaging are available on the 
channel. 


2. Mandatory if OEM payloads are available on the channel. 

3. Mandatory for standard payloads per Table 24-, Payload-specific Encryption Behavior, 
when a channel supports Cipher Suites that allow a session to be established with a 
standard Cipher Suite that supports encryption. 


24.1 Activate Payload Command 


This command is used for activating and deactivating a payload type under a given IPMI session. The ability to 
execute this command is determined via the user’s privileges as assigned via the Set User Payload Access 
command. 


The Activate Payload command may return a port number that is separate from the port number for the session 
that the command was issued under. In this case, the remote console must establish a session on the port number 
that the Activate Session command returned. The remote console must then issue the Activate Payload command 
on that port number in order to actually activate the payload. It is possible that the remote console already had a 
session active on the given port number. If the privileges associated with that session are sufficient (this will 
typically be the case unless the remote console activated the session at a privilege level that was lower than the 
maximum level for the user) the remote console can re-use the existing session and just use the Activate Payload 
command to activate the new payload type. 


BMCs may have limited resources for handling multiple sessions. It is highly recommended that a remote console 
avoids creating multiple sessions and shares sessions for multiple payloads whenever possible. 


The Activate Payload Command is only accepted over a channel on which payloads can be activated. E.g. the 
Activate Payload command cannot be executed from the IPMB. 
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Table 24-, Activate Payload Command 
byte data field 


Request Data [7:6] - reserved 

[5:0] - payload type (See Table 13-, Payload Type Numbers) IPMI Message 
payloads do not need to be explicitly activated. A payload that is 
required to be launched over a different port than that used to 
establish the initial IPMI session is only required to support the IPMI 
commands needed by the particular payload type. 

Payload Instance 

[7:4] - reserved 

[3:0] - payload instance. 1-based. Oh = reserved. 

Auxiliary Request Data. Additional payload-specific parameters to configure 

behavior of the payload when it becomes activated. Ignored if no auxiliary 

data is specified for given payload type. 


For Payload Type = SOL: 

byte 1 

[7] - Encryption Activation 

Note: the encryption algorithms specified in this document must be used 

with Authentication. The BMC will return an error completion code if an 

attempt is made to activate encryption without also activating 

authentication. 

1b: Activate payload with encryption. All SOL payload data from the 

BMC will be encrypted, if encryption was negotiated at the time of 
session activation. 

Ob: Activate payload without encryption. BMC will send all SOL 
payload data unencrypted, if that option is allowed. (An SOL 
configuration parameter allows a system to be configured to 
require encryption for all SOL transfers) 

[6] - Authentication Activation 

1b: Activate payload with authentication. All SOL payload data from 
the BMC will be authenticated, if authentication was negotiated at 
the time of session activation. 

Ob: Activate payload without authentication. BMC will send all SOL 
payload data unauthenticated, if that option is allowed. (An SOL 
configuration parameter allows a system to be configured to 
require authentication for all SOL transfers) 

Test Mode (optional). Enables DCD/ and DSR to be manually 
controlled by the remote console and the reporting of RTS and 
DTR state via the SOL Operation/Status byte. This can be used to 
facilitate software testing of the 16550 UART interface. 
1b = activate test mode. If test mode is not supported, bit [0] of the 
auxiliary response data will be returned as Ob. 
Ob = deactivate test mode 
[4]- reserved 
[3:2] - Shared Serial Alert Behavior 
The following settings are determine what happens to serial alerts if IPMI 
over Serial and SOL are sharing the same baseboard serial controller. 
Reserved 
Serial/modem alerts succeed while SOL active. 
Serial/modem alerts deferred while SOL active. 
Serial/modem alerts fail while SOL active. 
SOL startup handshake 
BMC asserts CTS and DCD/DSR to baseboard upon activation. 
CTS and DCD/DSR remain deasserted after activation. Remote 
console must send an SOL Payload packet with control field 
settings to assert CTS and DCD/DSR. (This enables the remote 
console to first alter volatile configuration settings before 
hardware handshake is released). 
reserved 


byte 2:4 reserved - write a 00h 
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Response Data Completion Code 

Generic plus the following command-specific completion codes: 

(An error completion code should be returned if the payload type in the 

request is set to “IPMI Message” (Oh) ). 

80h: Payload already active on another session (required). 

This will be returned any time an attempt is made to activate a payload 

type when that type is already activated for another session, and when 
the BMC only supports one instance of that payload type running at a 
time. 

: Payload type is disabled (optional). Given payload type is not 
configured to be enabled for activation. 

: Payload activation limit reached. Cannot activate given payload type 
because the maximum number of simultaneous instances of that 
payload type are already running. 

: Cannot activate payload with encryption. 

: Cannot activate payload without encryption. BMC requires encryption 
for all payloads for given privilege level. 

Auxiliary Response Data. LS-byte first. 
For Payload = SOL: 
[31:1] - reserved. Return as Os 
[0] - Ob = test mode not supported / enabled 

1b = test mode enabled 
Inbound Payload Size 
Maximum size of payload data field from remote console to BMC. Excludes 
size of confidentiality header and trailer fields, if any. 1-based. 
Outbound Payload Size 
Maximum size of payload data field from BMC to remote console. Excludes 
size of confidentiality header and trailer fields, if any. 1-based. 
Payload UDP Port Number 
UDP port number that payload can be transferred over. If the port number is 
same as the port that was used to establish the IPMI session, then SOL 
payload transfers are now available under that IPMI session on that port. 
Otherwise, the remote console will need to establish a separate IPMI Session 
to the specified Port Number using the same IP Address, username and 
password/key information that was used to establish the IPMI session. SOL 
payload transfers will then be available over that session. 


If the remote console already has an IPMI session established on that port for 
a different payload type, the SOL payload type will now also be available over 
that session - provided that the session was established at a privilege level 
that matches the privilege level and authentication required for SOL. 
Otherwise, the remote console will need to close that session and re- 
establish it at the necessary privilege level. 


12:13 | Payload VLAN Number - FFFFh if VLAN addressing is not used. 


24.2 Deactivate Payload Command 


This command is used to terminate use of a given payload on an IPMI session. This type of traffic then becomes 
freed for activation by another session, or for possible re-activation under the present session. The Deactivate 
Payload command does not cause the session to be terminated. The Close Session command should be used for 
that purpose. A remote console application does not need to explicitly deactivate payload(s) prior to terminating a 
session. When a session terminates all payloads that were active under that session are automatically deactivated 
by the BMC. 
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Table 24-, Deactivate Payload Command 
byte data field 


Request Data [7:6] - reserved 

[5:0] - payload type (See Table 13-, Payload Type Numbers) 

Payload Instance 

[7:4] - reserved 

[3:0] - payload instance. 1-based. Oh = reserved. 

Payload Auxiliary Data. Additional parameters to configure behavior of the 

payload when it becomes deactivated. Ignored if no auxiliary data is specified 

for given payload type. 

For Payload Type = SOL: (no auxiliary data) write as 0000_0000h 

Response Data Completion Code 

Generic plus the following command-specific completion codes: 

(An error completion code should be returned if the payload type in the 

request is set to “IPMI Message” ( Oh ) ). 

80h: Payload already deactivated. 

81h: Payload type is disabled (optional). Given payload type is not 

configured to be enabled for activation. 


24.3 Suspend/Resume Payload Encryption Command 


This command enables a remote console to control whether payload data from the BMC is sent encrypted or not. 
Since encryption can be a significant burden on software, this command provides a mechanism to allow higher 
performance by operating without encryption and only activating encryption when it is required for data 
confidentiality. The command can also trigger a regeneration of the encryption Initialization Vector and re- 
initialization of the encryption state machine for algorithms such as xRC4 that use the same initialization vector 
for multiple packets. 


The extent at which this command can control encryption of data from the BMC is dependent on the payload 
definition. Some payload definitions may use a mix of encrypted and unencrypted payload data transfers. For 
example, a payload may implement a ‘request/response’ protocol, where the BMC would return an encrypted or 
unencrypted response based on whether the request from the remote console was encrypted or unencrypted. In this 
case, the command may only affect data that is autonomously generated by the BMC. Other payload definitions 
may just use whatever encryption the session was activated with, and offer no ‘run-time’ control of 
encryption/decryption, while other payload definitions may be ‘stream based’ where it is desirable for the remote 
console to be able to select when payload data is from the BMC is encrypted or not. 


The Suspend/Resume Payload Encryption command is only accepted from the channel that the payload was 
activated on. 


Table 24-, Payload-specific Encryption Behavior 
Payload Type = IPMI Messaging 
e Encrypted requests from the remote console will get encrypted responses from the BMC. 
e The Suspend/Resume Payload Encryption command controls whether asynchronous 
(unrequested) messages from the BMC are encrypted or not. 
e PET Traps (which are actually separate from IPMI Messaging) are always sent unencrypted. 
Payload Type = SOL 
e The SOL configuration parameters allow configuring the system to require that SOL data be 
encrypted. 
e The BMC will transmit SOL payload data according to encryption settings that were selected when 
the payload was activated unless over-ridden by SOL configuration parameters. 
e The Suspend/Resume Payload Encryption command controls whether SOL Payload data is 
encrypted or not. 
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Table 24-, Suspend/Resume Payload Encryption Command 


Request Data 


Response Data 


byte 


data field 


[7:6] - reserved 
[5:0] - payload type (See Table 13-, Payload Type Numbers) 


Payload Instance 
[7:4] - reserved 
3:0] - payload instance. 1-based. Oh = reserved. 


[ 

[7:2] - reserved 

[4:0] - Operation 

2h= Regenerate initialization vector. For xRC4 encryption, this causes 

the BMC to reinitialize the xRC4 state machine, reset the data 
offset, and deliver a new Initialization Vector value in the next 
encrypted packet it sends to the remote console. Because of 
processing delays and potential tasks in progress, the remote 
console may receive additional packets from the BMC that are 


encrypted using the prior Initialization Vector before getting packets 
that use the new IV. 


Resume/Start encryption on all transfers of specified payload data 
from the BMC. 
Suspend encryption on all transfers of specified payload messages 
from the BMC. 

Completion Code 

Generic plus the following command-specific completion codes: 

80h: Operation not supported for given payload type. 

81h: Operation not allowed under present configuration for given payload 

type. 
82h: Encryption is not available for session that payload type is active under. 
83h: The payload instance is not presently active. 


24.4 Get Payload Activation Status Command 


This command returns how many instances of a given payload type are presently activated, and how many total 


instances can be activated. 
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Table 24-, Get Payload Activation Status Command 
byte data field 

Request Data Payload Type Number - Type number of the standard payload type or OEM 

Payload Handle to retrieve status for. 

See Table 13-, Payload Type Numbers. 
Response Data Completion Code 

Instance capacity 
[7:4] - reserved. 


[3:0] - Number of instances of given payload type that can be simultaneously 
activated on BMC. 1-based. Oh = reserved. 


[7] - 1b = instance 8 is activated. 
Ob = instance 8 is deactivated. 
[6] - 1b = instance 7 is activated. 


Ob = instance 7 is deactivated. 


[0] - 1b = instance 1 is activated. 

Ob = instance 1 is deactivated. 
[7] - 1b = instance 16 is activated. 
Ob = instance 16 is deactivated. 
[6] - 1b = instance 15 is activated. 
Ob = instance 15 is deactivated. 


[0] - 1b = instance 9 is activated. 
Ob = instance 9 is deactivated. 


24.5 Get Payload Instance Info Command 


This command returns information about a specific instance of a payload type. It is primarily used by software 
that may want to negotiate with an application that is presently using the given payload type. It accomplishes this 
by using the Session ID returned from this command with the Get Session Info command to look up the 
addressing information for the party that activated the payload. The application may then use that information to 
establish a direct dialog with the application that presently ‘owns’ the payload (note that this inter-application 
communication is not defined in the IPMI specifications). 


Table 24-, Get Payload Instance Info Command 
byte data field 
Request Data Payload Type Number - Type number of the standard payload type or OEM 
Payload Handle to retrieve status for. 
See Table 13-, Payload Type Numbers. 
Payload Instance. 1-based. Oh = reserved. 


Response Data Completion Code 

An error completion code should be returned if the payload type in the 
request is set to “IPMI Message” ( Oh). 

Session ID - ID of session that instance is presently activated on. (The 
Managed System Session ID that the BMC generated when the 
session was activated). 00 00 00 00h if given instance is not 
activated. Remote software can use this information with the Get 
Session Info command to identify the remote console that presently is 
using a given payload type. 

Payload-specific information (8-bytes) 


For Payload Type = SOL: 

Byte 1: Port Number 
A number representing the system serial port that is being redirected. 
1-based. Oh = unspecified. Used when more than one port can be 
redirected on a system. 

Byte 2:8 = reserved. 
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24.6 Set User Payload Access Command 


IPMI v2.0 introduces the Set User Payload Access and Get User Payload Access commands. These commands 
can be thought of as extensions to the Set User Access and Get User Access commands, respectively. The Set User 
Payload Access command controls whether the specified user has the ability to activate the specified payload type 
on the given channel. 


The Set User Payload Access command uses bitfields to allow a configuration utility to use a single command to 
set enable/disable multiple payloads at a time. Standard payloads are set separately from OEM payload enables. 
The command would be issued at least once with Standard payloads selected to set the configuration for Standard 
payloads, and then at least once with OEM Payloads selected to set the configuration for OEM payloads. 


Table 24-, Set User Payload Access Command 
byte data field 


Request Data 1 Channel Number 
[7:4] - reserved 
[3:0] - Channel Number 
[7:6] - Operation 
00b = ENABLE. 
Writing a “1b” to enable/disable bit ENABLES corresponding 
payload. Writing “Ob” to bit causes no change to enabled/disabled 
state 
01b = DISABLE. 
Writing a “1b” to bit DISABLES corresponding payload. Writing Ob 
to bit causes no change to enabled/disabled state. 
10b, 11b = reserved 
[5:0] - User ID. 000000b = reserved. 


3 Standard Payload enables 1 
[7:2] - reserved for standard payloads 2-7 enable/disable bits 
[1] - standard payload 1 (SOL) enable/disable 

7 


[0] - reserved. Note: IPMI Messsaging is enabled/disabled for users via the 
Set User Access command. 


OEM Payload Enables 1 
[7] - OEM Payload 7 enable/disable 
[6] - OEM Payload 6 enable/disable 
[5] - OEM Payload 5 enable/disable 
[4] - OEM Payload 4 enable/disable 
[3] - OEM Payload 3 enable/disable 
[2] - OEM Payload 2 enable/disable 
[1] - OEM Payload 1 enable/disable 
[0] - OEM Payload 0 enable/disable 


OEM Payload Enables 2 - reserved 


Completion Code. 

Note: an implementation will not return an error completion code if the user 
access level is set higher than the privilege limit for a given channel. If it is 
desired to bring attention to this condition, it is up to software to check the 
channel privilege limits set using the Set Channel Access command and 
provide notification of any mismatch. 

1. The following commands remain available for payloads if IPMI Messaging Payload 
type is disabled: Deactivate Payload, Suspend/Resume Payload Encryption (as 
defined for given payload), Get Payload Activation Status, Get Channel Payload 
Version Command, Get Channel OEM Payload Info (if implemented), Set Session 
Privilege Level, and Close Session. 


Response Data 
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24.7 Get User Payload Access Command 


The Get User Payload Access command returns the user payload enable settings that were set using the Set User 
Payload Access command. 


Table 24-, Get User Payload Access Command 
byte data field 


Channel Number 
[7:4] - reserved 
[3:0] - Channel Number 


2 User ID 
[7:6] - reserved 


Request Data 


[5:0] - User ID. 000000b = reserved 


Response Data 1 Completion Code 


2 Standard Payload enables 1 
[7:2]- reserved for standard payloads 2-7 enabled/disabled state 
[1] - 1b = standard payload 1 enabled (SOL) 


Ob = standard payload 1 disabled 
[0] - reserved 


Standard Payload Enables 2 - reserved 


OEM Payload Enables 1. For each bit: 
1b = payload enabled 
Ob = payload disabled 
[7] - OEM Payload 7 enabled/disabled 
[6] - OEM Payload 6 enabled/disabled 
[5] - OEM Payload 5 enabled/disabled 
[4] - OEM Payload 4 enabled/disabled 


[3] - OEM Payload 3 enabled/disabled 
[2] - OEM Payload 2 enabled/disabled 
[1] - OEM Payload 1 enabled/disabled 
[0] - OEM Payload 0 enabled/disabled 
OEM Payload Enables 2 - reserved 


24.8 Get Channel Payload Support Command 


This command enables local and remote console software to determine what payloads are enabled on the given 
BMC. The command returns a bitfield indicating which Payload Type numbers can be activated on the given 
channel. 


342 


Intelligent Platform Management Interface Specification 


Table 24-, Get Channel Payload Support Command 


byte 
Request Data 


Response Data 1 


data field 


1 Channel Number 
[7:4] - reserved 
[3:0] - Channel Number 


Completion Code 


2 [7] = Standard payload type #7 supported 
[0] = Standard payload type #0 supported 


[7] = Standard payload type #15 (OFh) supported 
[0] = Standard payload type #8 supported 


3 
4 


[7] = Session Setup payload type #7 supported 


[0] = Session Setup payload type #0 supported 


5 [7] = Session Setup payload type #15 (OFh) supported 
[0] = Session Setup payload type #8 supported 


[7] = Payload type 27h (OEM7) used 


[0] = Payload type 20h (OEMO) used 
[7] = Payload type 2Fh (OEM15) used 


[0] = Payload type 28h (OEM8) used 
reserved. Return as 0000h 


24.9 Get Channel Payload Version Command 


This command returns version information for the given payload type. The version number has major and minor 
parts. The major part of the version should only increment when there are significant changes to the payload 
format, commands, or payload-specific protocols that break backward compatibility with earlier versions. The 
minor part of the version increments when there are extensions to the payload format that are significant but are 
backwards compatible with earlier versions under the same major version number. An example of a major change 


would be a change to the payload 


activation process that would prevent earlier applications from activating the 


given payload type. An example of a minor format version change would be the definition of commands for new 


functions that did not exist under 
applications. 


the previous format, but if unused, do not interfere with the operation of older 
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Request Data 


Response Data 


Table 24-, Get Channel Payload Version Command 


Channel Number 

[7:4] - reserved 

[3:0] - Channel Number 

Payload Type Number / Payload Type Handle - number of the standard 

payload type or OEM Payload Handle to retrieve status for. 

See Table 13-, Payload Type Numbers. 

Completion Code. Generic plus following command-specific completion 
codes: 

80h - Payload type not available on given channel. 


Format Version 
[7:4] - Major Format Version. BCD encoded (0 to 9) 
[3:0] - Minor Format Version. BCD encoded. (0 to 9) 
Software should present version data to the user in the format 
*major.minor” - e.g. 10h > “1.0” 


The Format Version for the SOL payload implemented per this specification is 


24.10 Get Channel OEM Payload Info Command 


This command provides a mechanism for software to determine the OEM Payload Type Number that corresponds 
to a particular type of OEM Payload, or vice versa. The command also returns the format version of the payload. 
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Table 24-, Get Channel OEM Payload Info Command 


Request Data 


Response Data 


Channel Number 
[7:4] - reserved 
[3:0] - Channel Number 


Payload Type Number. (See Table 13-, Payload Type Numbers). Use “OEM 
Explicit” to look up information by OEM IANA/OEM Payload ID. 


OEM IANA. When Payload Type Number is 02h (OEM Explicit) this field 
holds the OEM IANA for the OEM payload type to look up information 
for. Otherwise, this field is set to 00 00 OOh. 


OEM Payload ID. When Payload Type Number is 02h (OEM Explicit) this field 
holds the OEM Payload ID for the OEM payload type to look up 
information for. Otherwise, this field is set to 0000h. 


Completion Code 


80h = OEM Payload IANA and/or Payload ID not supported. 


Payload Type Number. (See Table 13-, Payload Type Numbers) This is 
always returned as the OEM Payload Type number (OEMO-OEM7). 
“OEM Explicit” is not returned for this parameter. 


OEM IANA. IANA for the OEM that has defined the OEM payload type. 


OEM Payload ID. Payload ID value, specified by the OEM the defined the 
payload type. 


Format Version 

[7:4] - Major Format Version. BCD encoded (0 to 9) 

[3:0] - Minor Format Version. BCD encoded. (0 to 9) 
Software should present version data to the user in the format 
“major.minor” - e.g. 10h > “1.0” 
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25. IPMI Serial/Modem Commands 


This section defines the configuration and control commands that are specific to serial/modem channels. None of 


the commands in the following table are required unless a serial/modem channel is implemented. Refer to 


Appendix G - Command Assignments 


for the specification of the Network Function and Command (CMD) values and privilege levels for these 


commands. 


Table 25-, IPMI Serial/Modem Commands 


Command 


Section 
Defined 


Set Serial/Modem Configuration 


25.1 


Get Serial/Modem Configuration 


25.2 


Set Serial/Modem Mux 


25.3 


Get TAP Response Codes 


25.4 


Set PPP UDP Proxy Transmit Data 


25.5 


Get PPP UDP Proxy Transmit Data 


25.6 


Send PPP UDP Proxy Packet 


25.7 


Get PPP UDP Proxy Receive Data 


25.8 


Serial/Modem Connection Active 


25.9 


SO OO OO SE 


=| 5| 5| 5| 5| 9 N 


Callback 


25.10 


O 


Set User Callback Options 


25.11 


Gi 


Get User Callback Options 


Mandatory if serial/modem channel(s) supported. 
Mandatory if Serial Port Sharing is supported. 


Mandatory if TAP Paging is supported. If TAP Paging is supported it is 


25.12 


OO 


recommended, but not mandatory, that it be supported on all serial/modem 


channels that could support a modem connection. (Some serial/modem channels 


may never be connected to a modem) 
Mandatory if PPP UDP Proxy capability is supported. 


configuration parameters. 


25.1 Set Serial/Modem Configuration Command 


Gi 


Mandatory if IPMI Callback is supported. Note that CBCP callback support is 
optional. Whether CBCP is supported or not is determined from the serial/modem 


This command is used for setting parameters such as the string used for initializing the modem, communication 


bit rates, and selecting configuration options such as Direct Connect versus Modem Connect. 


Table 25-, Set Serial/Modem Configuration Command 


byte data field 


Request Data [7:4] - reserved 


Response Data 


[3:0] - Channel number. 


Parameter selector 


Configuration parameter data, per Table 25-, Serial/Modem Configuration 


Parameters 


codes: 


80h = parameter not supported. 


Completion Code. Generic plus the following command-specific completion 


81h = attempt to set the ‘set in progress’ value (in parameter #0) when not in 
the ‘set complete’ state. (This completion code provides a way to 
recognize that another party has already ‘claimed’ the parameters) 

82h = attempt to write read-only parameter 

83h = attempt to read write-only parameter 
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25.2 Get Serial/Modem Configuration Command 


This command is used for retrieving the configuration parameters from the Set Serial/Modem Configuration 
command. 
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Table 25-, Get Serial/Modem Configuration Command 


Request Data 


Response Data 


byte data field 


[7]- Ob = get parameter 

1b = get parameter revision only 
[6:4] - reserved 
[3:0] - Channel number. 


Parameter selector 


Set Selector. Selects a particular set or block data under the given parameter 
selector. 00h if parameter does not use a set selector. 


Block Selector (00h if parameter does not require a block number) 
Completion Code. Generic plus the following command-specific completion 
codes: 
80h = parameter not supported. 
[7:0] - Parameter revision. 
Format: MSN = present revision. LSN = oldest revision parameter is 
backward compatible with. 11h for parameters in this specification. 
The following data bytes are not returned when the ‘get parameter revision 
only’ bit is 1b. 


Configuration parameter data, per Table 25-, Serial/Modem Configuration 
Parameters 

If the rollback feature is implemented, the BMC makes a copy of the existing 
parameters when the ‘set in progress’ state becomes asserted (See the Set In 
Progress parameter #0). While the ‘set in progress’ state is active, the BMC 
will return data from this copy of the parameters, plus any uncommitted 
changes that were made to the data. Otherwise, the BMC returns parameter 
data from non-volatile storage. 
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Table 25-, Serial/Modem Configuration Parameters 


Parameter 


Set In Progress 
(volatile) 


# 
0 


Parameter Data (non-volatile unless otherwise noted)!" 


data 1 - This parameter is used to indicate when any of the following parameters are 
being updated, and when the updates are completed. The bit is primarily provided to alert 
software than some other software or utility is in the process of making changes to the 
data. 

An implementation can also elect to provide a ‘rollback’ feature that uses this information 
to decide whether to ‘roll back’ to the previous configuration information, or to accept the 
configuration change. 

If used, the roll back shall restore all parameters to their previous state. Otherwise, the 
change shall take effect when the write occurs. 

[7:2] - reserved 


[1:0] - 00b = set complete. If a system reset or transition to powered down state occurs 

while ‘set in progress’ is active, the BMC will go to the ‘set complete’ state. 
If rollback is implemented, going directly to ‘set complete’ without first doing 
a ‘commit write’ will cause any pending write data to be discarded. 

01b = set in progress. This flag indicates that some utility or other software is 
presently doing writes to parameter data. It is a notification flag only, it is 
not a resource lock. The BMC does not provide any interlock mechanism 
that would prevent other software from writing parameter data while. 

10b = commit write (optional). This is only used if a rollback is implemented. The 
BMC will save the data that has been written since the last time the ‘set in 
progress’ and then go to the ‘set in progress’ state. An error completion 
code will be returned if this option is not supported. 

11b = reserved 


Authentication Type 
Support (Read Only) 


This ‘read only’ field returns which possible Authentication Types (algorithms) can be 
enabled for the given channel. The following Authentication Type Enables parameter 
selects which Authentication Types are available when activating a session for a 
particular maximum privilege level. 


[7:6] -reserved 
[5:0] - Authentication type(s) enabled for this channel (bitfield): 
All bits: 1b = supported 

Ob = authentication type not available for use. 


[5] - OEM proprietary (per OEM identified by the IANA OEM ID in the RMCP Ping 
Response) 

[4] - straight password / key 

[3] - reserved 

[2] - MD5 

[1] - MD2 

[0] - none 
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Parameter 


Authentication Type 
Enables 


+ 


Parameter Data (non-volatile unless otherwise noted)" 


This field is used to configure which Authentication Types are available for use when a 
remote console activates an IPMI messaging connection to the BMC for a given 
requested maximum privilege level. Once the session has been activated, the accepted 
authentication type will be the only one used for authenticated packets, regardless of the 
present operating privilege level, or the privilege level associated with the command. 


Depending on configuration of per-message and user-level authentication disables, 
unauthenticated packets (authentication type = none) may also be accepted. The BMC 
makes no attempt to check or ensure that stricter authentication types are associated with 
higher requested maximum privilege levels. E.g. it is possible to configure the BMC so 
activating a session with a maximum privilege level of ‘User’ requires MD5 while ‘Admin’ 
requires ‘none’. 


Note: An implementation that has fixed privilege and authentication type assignments, in 
which case this parameter can be implemented as Read Only. It is recommended that an 
implementation that implements a subset of the possible authentication types returns a 

CCh error completion code if an attempt is made to select an unsupported authentication 


type. 


byte 1: Authentication Types returned for maximum requested privilege = Callback level. 
[7:6] -reserved 
[5:0] -Authentication type(s) enabled for this channel (bitfield): 
All bits: 1b = authentication type enabled for use at given privilege level 
Ob = authentication type not available for use at given privilege level. 

[5] - OEM proprietary (For PPP, per OEM identified by the IANA OEM ID in the 
RMCP Ping Response. For other serial/modem modes, a-priori knowledge of 
the algorithm is required.) 

[4] - straight password / key 

[3] - reserved 


[2]- MD5 
[1] - MD2 
[0] - none 


byte 2: Authentication Type(s) for maximum privilege = User level 
(format follows byte 1) 


byte 3: Authentication Type (s) for maximum privilege = Operator level 
(format follows byte 1) 


byte 4: Authentication Type (s) for maximum privilege = Administrator level 
(format follows byte 1) 


byte 5: Authentication Type (s) for maximum privilege = OEM level 
(format follows byte 1) 
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Parameter # Parameter Data (non-volatile unless otherwise noted)! 
Connection Mode 3 data 1 - connection mode - This parameter determines the protocols used when 
performing IPMI messaging to the BMC. 
[7] - Ob = Modem Connect mode 
1b = Direct Connect mode 
[6] - reserved 
Connection mode enables. 
Sets which mode or modes can be used for establishing an IPMI Messaging connection 
with the BMC. If more than mode is enabled, the BMC will attempt to auto-detect the 
appropriate connection mode based on snooping traffic from the remote console. 
Supporting connection mode auto-detect is optional. If an implementation does not 
support the capability, it shall return an “Illegal Data Field” completion code (CCh) if an 
attempt is made to enable more than one connection mode at a time. An ‘Illegal Data 
Field’ code shall also be returned if an attempt is made to enable a connection mode that 
the implementation does not support. 
[5:3] - reserved 
[2] - 1b = enable Terminal mode 
(Note: Terminal mode auto-detect also requires that the “Enable 
Baseboard-to-BMC switch on <ESC>(* option be enabled in the Mux 
Switch Configuration parameters, below.) 
[1] - 1b = enable PPP mode 
[0] - 1b = enable Basic mode 
Session Inactivity Timeout 4 [7:4]- reserved 
(optional) [3:0] - Inactivity timeout in 30 second increments. 1-based. Oh = session does not 


timeout and close due to inactivity. 
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Parameter 
Channel Callback Control 


Parameter Data (non-volatile unless otherwise noted)! 

This is parameter determines which callback options are enabled or disabled for the 
channel. These parameters take precedence over any user-specific callback settings 
configured using the Set User Callback Options command. An option must be enabled in 
this global parameter in order to be able to be enabled in the user-specific callback 
settings. (see 25.11, Set User Callback Options Command). 


data 1 - callback enable 

[7:2]- reserved 

[1] - 1b = enable CBCP callback protocol (see 14.6.1, Callback Control Protocol 
(CBCP) Support) 

[0] - 1b = enable IPMI callback 


data 2 - CBCP Negotiation Options. 
[7:4] - reserved. 


[3] - 1b = enable callback to one from list of possible numbers 

[2] - 1b = enable user-specifiable callback number. Allow caller to specify number to 
be used for callback. 

[1] - 1b = enable Pre-specified number. Allow caller to request that callback occur to a 
single, pre-specified number for the user. 

[0] - 1b = enable No Callback. Allow caller to request that callback not be used. 


data 3 Callback destination 1. This field holds a Destination Selector that picks which 
Destination Dial String from the serial/modem configuration parameters to use for 
callback. This selector is used when the ‘pre-specified number’ option is used. 
Otherwise, this is the first number in the list when the “caller selects one number 
from a list of numbers” option is used. Refer to 14.6.1, Callback Control Protocol 
(CBCP) Support for characters supported in dial strings for CBCP. 

FFh = unspecified. 
Note, if this field is set to FFh, the BMC should reject negotiation for the ‘pre- 
specified number’ option, even if it is enabled in the CBCP Negotiation Options 
field, above. 


data 4 Callback destination 2. This is the second number in the list when the “caller 
selects one number from a list of numbers” option is used. 

FFh = unspecified. 
Note, at least one destination must be specified in order for the ‘callback to one 
from a list of numbers’ option to be negotiated, even it that option is enabled in 
the CBCP Negotiation Options field, above. 


data 5 Callback destination 3. This is the third number in the list when the “caller selects 
one number from a list of numbers” option is used. 

FFh = unspecified. 
Note, at least one destination must be specified in order for the ‘callback to one 
from a list of numbers’ option to be negotiated, even it that option is enabled in 
the CBCP Negotiation Options field, above. 


Session Termination 


data 1 - connection termination. This parameter determines whether serial/modem 
connections are terminated by inactivity or by a loss of DCD. For modem mode, the line is 
hung-up when the specified termination condition occurs. For both modem and direct 
connect mode, the session will be terminated and will need to be reactivated and 
authenticated (if authentication is enabled) in order for IPMI messaging communications 
to be re-established. 

[7:2] - reserved 


[1]- 1b = enable session inactivity timeout 
Ob = disable session inactivity timeout 
[0] - 1b = close session on loss of DCD (this should be used as the default setting for 


both Modem Connect and Direct Connect mode) [Also see bit to enable mux 
switch on DCD assertion, in Mux Switch Control parameter, below] 
Ob = ignore DCD (DCD is never ignored in Modem Mode) 


350 


Intelligent Platform Management Interface Specification 


Parameter 


IPMI Messaging Comm 
Settings 


+ 


Parameter Data (non-volatile unless otherwise noted)! 
This parameter is used for IPMI messaging in PPP Mode, Basic Mode, and Terminal 
Mode. These settings can be overridden on a per-destination basis for Dial-out LAN 
Alerting, Dial-Paging, TAP Paging, and Callback Security, according to the Destination 
Comm Settings parameter, below. 
IPMI Messaging always occurs with 8 bits/character, no parity, and 1 stop bit. 
data 1 - flow control, DTR hang-up, asynch format 
[7:6] - Flow control 
00b = No flow control 
01b = RTS/CTS flow control (a.k.a. hardware handshake) 
10b = XON/XOFF flow control (optional) [if implemented, may not be supported for 
all connection modes] 

11b = Reserved. 
[5] - DTR hang-up 
Ob = disable DTR hang-up 
1b = enable DTR hang-up 
[4:0]- reserved. 


data 2 - bit rate 

[7:4]- reserved 

[3:0] - 0-5h = reserved. Support for bit rates other than 19.2 kbps is optional. The BMC 
must return an error completion if a requested bit rate is not supported. It is 
recommended that the ‘parameter out-of-range’ (C9h) code be used for this 
situation. 

6h = 9600 bps 

7h = 19.2 kbps (required) 

8h = 38.4 kbps 

9h = 57.6 kbps 

Ah = 115.2 kbps 
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Parameter # Parameter Data (non-volatile unless otherwise noted)!" 
Mux Switch Control 8 data 1 
See 14.2.4, Serial Port Switching for additional information on these bits. Bit [3] is only 
applicable if PPP Mode is supported. 
[7] - reserved 
[6] - Ob = Disable system power-up/wakeup via [MSVT] <ESC>" escape sequence 
1b = Enable system power-up/wakeup via [MSVT] escape sequence? BI 
[5] - Ob = Disable hard reset on [MSVT] <ESC>R<ESC>r<ESC>R escape sequence 
1b = Enable hard reset on [MSVT] escape sequence?! 
[4] - Ob = Disable Baseboard-to-BMC switch on detecting basic mode Get Channel 
Authentication Capabilities message pattern in serial stream. 
1b = Enable Baseboard-to-BMC switch on detecting basic mode Get Channel 
Authentication Capabilities message pattern in serial stream. 
[3] - Ob = Disable switch to BMC on PPP IPMI-RMCP pattern 
1b = Enable switch on PPP IPMI-RMCP pattern 
[2] - Ob = Disable BMC-to-Baseboard switch on [MSVT] <ESC>Q 
1b = Enable BMC-to-Baseboard switch on [MSVT] <ESC>QR! 
[1] - Ob = Disable Baseboard-to-BMC switch on [MSVT] <ESC>( 
1b = Enable Baseboard-to-BMC switch on [MSVTI-ESC-(SI! 
[0] - Following only used in Direct Connect Mode (ignored in Modem Mode) 
Ob = Disable mux switch to BMC on DCD loss 
1b = Enable mux switch on DCD loss 
data 2 
[7:4]- reserved 
[3]-  Ob= Disable Serial Port Sharing. (cannot force mux setting via Set 
Serial/Modem Mux command) 
The serial connection is assigned to the BMC whenever the channel is 
enabled, and cannot be switched to the baseboard UART. Note: if this 
setting is Ob and the serial/modem channel is disabled, the mux will be 
connected to the baseboard UART and will not be able to be switched to 
the BMC by IPMI command. If Serial Port Sharing is not implemented, 
this bit will always be set to ‘disabled’ and will not be changeable. 
{b= Enable Serial Port Sharing (can force mux setting using Set 
Serial/Modem Mux command) 
[2]- Ob= Disable Serial/Modem Connection Active message during Callback 
connection. 
1b= Enable Serial/Modem Connection Active message during Callback 
connection. 
[1]- Ob= Disable Serial/Modem Connection Active message during direct-call 
1b= Enable Seria/Modem Connection Active message during direct-call 
[0]- Ob= Send Serial/Modem Connection Active message only once before 
switching mux to system 
{b= Mux switch acknowledge. Retry Seria/Modem Connection Active 
message with retry counts and interval as specified in Section 14.3.2, 
Mux Switch Coordination. 
Modem Ring Time 9 Configures the amount of time that the BMC needs to see transitions or an active state on 


RI before the BMC claims the mux in Modem Mode. 


This setting only applies when the Access Mode is set to “Shared” or “Pre-boot Only”, 
Serial Port Sharing is enabled, the channel is enabled for IPMI Messaging. This includes 
when the system is powered down, in order to allow the possibility for using “Wake On 
Ring” to trigger a wake of the system without causing the BMC answering the phone. See 
14.2.7, Serial Port Sharing Access Characteristics for additional information. 


data 1 - Ring Duration 

[7:6]- reserved 

[5:0] - Ring duration in 500 ms increments. 1 based. 
00_0000b = BMC switches mux immediately on first detected transition of RI. 
11_1111b (3Fh) = reserved 


data 2 - Ring Dead Time 

[7:4]- reserved 

[3:0] - Amount of time, in 500 ms increments, that the RI signal must be deasserted 
before the BMC determines that ringing has stopped. Oh = 500 ms. 
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Parameter 
Modem Init String 


Parameter Data (non-volatile unless otherwise noted)" 

Sets the modem initialization string data. The BMC automatically follows this string with 

an <enter> character when sending it to the modem. 

data 1 - set selector = 16-byte block number to set, 1 based. Two blocks required, at 
least three recommended. 

data 2:N - Modem Init string data. String is stored as null terminated ASCII string. 


Modem Escape Sequence 
(optional) 


11 


data1:5- Null terminated ASCII string for the Escape string to be sent to the modem. If this 
parameter is empty, or this configuration option is not implemented, the default ‘+++’ 
sequence will be used. [If a full five characters are provided, the last character does not 
need to be null] 


Modem Hang-up 
Sequence (optional) 


12 


data1:8 - Null terminated ASCII string for the hang-up string to be sent to the modem. The 
BMC automatically follows this string with an <enter> character when sending it to the 
modem. If this parameter is empty, or this configuration option is not implemented, the 
default ‘ATH’ sequence will be used. [If a full eight characters are provided, the last 
character does not need to be null] 


Modem Dial Command 
(optional) 


13 


data1:8 - Null terminated ASCII string for the modem string used to initiate a dial 
sequence with the modem. If this parameter is empty, or this configuration option is not 
implemented, the default ‘ATD’ sequence will be used. [If a full eight characters are 
provided, the last character does not need to be null] 


Page Blackout Interval 


14 


data 1 - Dial Page, Directed Alert, or TAP Blackout Interval in minutes. 1 based. 00h = no 
blackout. See Section 14.10, Page Blackout Interval for more information. 


Community String 


15 


data 1:18 - Community String 

Default = ‘public’. Used to fill in the ‘Community String’ field in a PET format trap. This 
string may optionally be used to hold a vendor-specific string that is used to provide the 
network name identity of the system that generated the event. Printable ASCII string. If 18 
non-null characters are provided, the last character does not need to be a null. 18 
characters must be written when setting this parameter, and 18 will be returned when this 
parameter is read. The null character, and any following characters, will be ignored when 
the Community String parameter is placed into the PET. The BMC will return whatever 
characters were written. l.e. it will not set bytes following the null to any particular value. 
(Community strings are supported on a ‘per channel’ basis in order to allow the possibility 
that a different Community String would be used based on the type of connection.) 


Number of Alert 
Destinations 
(READ ONLY) 
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data 1 - Number of non-volatile Alert Destinations for this channel. Destination 0 is always 

present as a volatile destination that is used with the Alert Immediate command. 

[7:5]- reserved. 

[3:0] - Number of non-volatile alert destinations. One minimum, fifteen non-volatile 
destinations maximum. It is recommended that an implementation provide at least 
two destination numbers for each page/alert type supported, plus two for callback 
if callback is supported. 

Oh = Page Alerting not supported. 


Destination Info 
(volatile) & 
(non-volatile) - see 
description. 


17 


Sets the type of page associated with the given destination. For Dial Page, TAP Page, 
and Callback, this also selects the dial string associated with the destination. Destination 
0 is used to set a temporary, RAM-based, value. This value is used with the Alert 
Immediate command. The value is not guaranteed to be retained across BMC or system 
hard resets or power on/off transitions. 


data 1 - Destination Selector 
A minimum of one and a maximum of fifteen non-volatile destinations are supported in 
the specification. If callback is supported, the callback number is also a type of 
destination. Destination 0 is always present as a volatile destination that is used with 
the Alert Immediate command. 
[7:4] -reserved 
[3:0] - destination selector. 
Oh = volatile destination. 
1-Fh = non-volatile destination. 


data 2 - Destination Type 
[7] - Alert Acknowledge. Note, some alert types, such as Dial Page, do not support 
acknowledge, in which case this bit is ignored and should be written as 
Ob. 
Ob = Unacknowledged. Alert is assumed successful if transmission occurs 
without error. This value is also used with Callback numbers. 
1b= Acknowledged. Alert is assumed successful only if acknowledged is 
returned. 
[6:4] - reserved 
[3:0] - Destination Type: 
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(non-volatile) 


Parameter # Parameter Data (non-volatile unless otherwise noted)!" 
0000b = Dial Page 
0001b = TAP Page 
0010b = PPP Alert (PET Alert delivered via a PPP-to-LAN connection) 
0011b = Basic Mode Callback 
0100b = PPP Mode Callback 
0101b:1101b = reserved 
1110b = OEM 1 
1111b = OEM 2 
data 3 - Alert Acknowledge Timeout, in seconds, 0-based (i.e. minimum timeout = 1 
second). Recommended factory default = 5 seconds. Value is ignored if alert type does 
not support acknowledge, or if the Alert Acknowledge bit (above) is Ob. 
data 4: Retries 
[7]- reserved 
[6:4]- Number of times to retry alert once call connection has been made. (Does not 
apply to TAP Page or Dial Page alerts) 
1-based. 000b = no retries (alert is only sent once). 
[3] - reserved 
[2:0]- Number of times to retry call to given destination. (See below for Call Retry 
Interval parameter) 1-based. 000b = no retries (call is only tried once). 
data 5: Destination Type Specific: 

For Destination Type = Dial Page: 

[7:4]- Dial String Selector 

[3:0] - reserved 

For Destination Type = TAP Page: 

Indicates which set of TAP Service Settings should be used for communication with this 

destination. 

[7:4] - reserved 

[3:0] - TAP Account Selector 

For Destination Type = PPP Alert: 

Indicates which set of PPP Account settings should be used for communication with the 

selected destination. 

[7:4] - Destination IP Address Selector 

[3:0] -PPP Account Set Selector 

For Destination Type = PPP Mode Callback or Basic Mode Callback: 

[7:4] - = Destination IP Address Selector for PPP Mode Callback (The IP Address is 
used to enable the BMC to send a Serial/Modem Connection Active 
message once the connection has been established.) 

= Dial String Selector for Basic Mode Callback 
[3:0] - PPP Account Set Selector (PPP Mode Callback only, reserved otherwise) 
Call Retry Interval 18 [7:0] -Number of seconds between call (‘busy signal’) retries. 
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Parameter # Parameter Data (non-volatile unless otherwise noted)!" 
Destination Comm 19 data 1 - Destination Selector 
Settings Note that each destination has its own comm settings. 
(volatile) & [7:4] -reserved 
(non-volatile) - see [3:0] - Destination Selector. 
description. 0 = volatile destination. 
1-Fh = non-volatile destination. 
Destination comm settings. These settings override the IPMI Messaging Comm Setting 
configuration parameter. 
data 2 - flow control, DTR hang-up, asynch format 
[7:6] - flow control 
00b = No flow control 
01b = RTS/CTS flow control 
10b = XON/XOFF flow control 
11b = reserved 
[5] - reserved 
[4] - stop bits 
Ob = 1 stop bit (default) 
1b = 2 stop bits 
[3] - character size 
Ob = 8 bits (must be 8-bit for PPP) 
1b = 7-bits (most TAP services use 7-bit) 
[2:0] - parity 
000b = no parity. 
001b = odd parity. 
010b = even parity 
data 3 - bit rate 
[7:4]- reserved 
[3:0] - bit rate 
0-5h = reserved 
6h = 9600 bps 
7h = 19.2 kbps (required) 
8h = 38.4 kbps 
9h = 57.6 kbps 
Ah = 115.2 kbps 
Number of Dial Strings 20 data 1 - Number of non-volatile Dial Strings for this channel. Dial String 0 is always 
(READ ONLY) present and is typically used as a volatile destination that is used with the Alert Immediate 
command. 
[7:5]- reserved. 
[3:0] - Number of non-volatile dial strings. One minimum, fifteen non-volatile dial strings 
maximum. An implementation should support one dial string for each destination. 
Oh = Serial/Modem Alerting and Callback not supported. 
Destination Dial Strings 21 Sets the phone number that the page, alert is to be sent to. The BMC automatically 
(volatile) & precedes this string with the Modem Init String sequence, when not using direct connect 
(non-volatile) - see deer D de can ec embedded modem control sequence characters. 
inti ata 1 - destination selector 
description. Al reserved 
[3:0] - Dial String Selector. 
0 = volatile dial string 
1-Fh = non-volatile dial string. 
data 2 - block number to set, 1 based. 
Blocks are 16-bytes. At least two blocks are required per number, supporting a dial 
string of 31 characters plus terminator. 
data 3:N - Dial string data. Null terminated ASCII string. 
Number of Alert 22 data 1 - Number of non-volatile Alert Destination IP Addresses for this channel. Address 0 
Destination IP Addresses is always present and is typically used as a volatile destination that is used with the Alert 
(READ ONLY) Immediate command. It is recommended that there be at least one destination IP Address 


per PPP Account. 
[7:5]- reserved. 
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Parameter 


Parameter Data (non-volatile unless otherwise noted)!"! 


[3:0] - Number of Destination IP Addresses. Oh = PPP Alerting and Callback are not 
supported. 


Destination IP Addresses 
(volatile) & (non-volatile) - 
See description. 


23 


data 1 - destination selector 
[7:4] -reserved 
[3:0] - Destination IP Address Selector. 
0 = volatile IP Address location 
1-Fh = non-volatile IP Address 
data 2:5 - destination IP Address. MS-byte first. 


Number of TAP Accounts 
(READ ONLY) 


24 


data 1 - Number of non-volatile TAP Accounts for this channel. Account 0 is always 
present and is typically used as a volatile destination that is used with the Alert Inmediate 
command. It is not included in the count. 

[7:5]- reserved. 

[3:0] Number of TAP Accounts. Oh = TAP not supported. 


TAP Account 


25 


data 1 - set selector = TAP Account Selector, 1-based. At least one set of TAP Account 
parameters must be provided for each TAP destination supported. Account 0 is always 
present and is typically used as a volatile destination that is used with the Alert Inmediate 
command. 


data 2 - TAP Dial String and Service Setting selectors 
[7:4] - Dial String Selector 
[3:0] - TAP Service Settings Selector. 1-based. Oh if Destination Type is not ‘TAP Page’ 


TAP Passwords 
(WRITE ONLY) 
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data 1 - set selector = TAP Account selector, 1 based. 
data 2:8 - Password. This string is up to six ASCII characters. Null terminated if fewer 
than six characters are used. 


TAP Pager ID Strings 


27 


This parameter sets and returns the TAP Pager ID (also referred to as ‘Field 1’) for the 

specified destination. This typically holds the phone number of the party to be paged. 

Note that some paging services will reject transactions that have an empty Field 1. 

data 1 - set selector = TAP Account selector, 1 based. 

data 2:17 - Pager ID String. This string is up to 16 ASCII characters. Null terminated if 
fewer than 16 characters are used. The string will be transmitted with escaping as 
specified by the control-character escaping mask for the given destination. 


TAP Service Settings 


28 


This parameter is used to configure one or more sets of values related to strings, 
escaping, and timeouts and retries associated with a TAP paging service. The timing 
parameters are per [TAP], with the exception of T6 and N4, which are extended 
parameters for this specification. There must be at least one set of TAP Service Setting 
parameters supported if TAP paging is supported on this channel. 


data 1 - set selector = TAP Service Setting Selector 

There is a 1:1 association between the TAP Parameter selector in this row, and the 
selector in the previous row. Parameter fields that share the same parameter selector 
form a parameter set. 

[7:4] -reserved 

[3:0] - TAP Parameter selector. 1-based. (0 = volatile paramters) 


data 2 - TAP Confirmation 

[7:2]- reserved. 

[1:0]- confirmation. This parameter determines what criteria is used by PEF and the 
Alert Immediate command to determine that a TAP Page was successfully 
delivered to the paging service. 
00b = ACK received after end-of-transaction only 
01b = code 211 and ACK received after ETX 
10b = code 211or 213, and ACK, received after ETX 
11b = reserved 


data 3:5 - TAP ‘SST’ Service Type field characters, in ASCII. Default = “PG1”. 
Three characters must be provided. 


data 6:9 - TAP Control-character escaping mask. (Default = FFFF_FFFFh) 

[31:0] - each bit position represents escaping for corresponding control characters 31h 
through OOh. A bit value of 1b = escape the character. Ob = don’t escape the character. 
This bit value is ignored for characters that a required to be escaped by TAP. By default, 
all control characters are escaped. 


data 10 - timeout parameters 1 
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Parameter # Parameter Data (non-volatile unless otherwise noted)" 
[7:4] TAP T2 - timeout in 500 ms. 0-based (Oh = 500 ms). Default = 1h (1 second) 
[3:0] TAP T1 - timeout in seconds. 0-based (Oh = 1 second). Default = 1h (2 seconds) 
data 11 - timeout parameters 2 
[7:4] TAP T4 - timeout in seconds. 0-based (Oh = 1 second). Default = 3h (4 seconds) 
[3:0] TAP T3 - timeout in 2 second increments. O-based (Oh = 2 seconds). Default = 
4h (10 seconds) 
data 12 - timeout parameters 3 
[7:4] IPMI T6 - IPMI timeout waiting for end-of-transaction acknowledge, in seconds. 
0-based (0 = 1 second). Default = 1h (2 seconds). 
[3:0] TAP T5 - timeout in 2 second increments. O-based (Oh = 2 seconds). Default = 
3h (4 seconds) 
data 13 - retry parameters 1 
[7:4] TAP N2 - retries. 1-based. (0 = no retry). Default = 3. 
[3:0] TAP N1 - retries. 1-based. (0 = no retry). Default = 3. 
data 14 - retry parameters 2 
[7:4] IPMI N4 - number of retries for end-of-transaction. Default = 3. 
[3:0] TAP N3 - retries. 1-based. (0 = no retry). Default = 3. 
Terminal Mode 29 This parameter and its fields only apply when Terminal Mode is enabled. The non-volatile 
Configuration! parameters are the initial values used whenever a terminal mode session is first 
established. The settings are returned to the non-volatile settings when a loss of DCD is 
detected and whenever the Terminal Mode session is deactivated. 
data 1 
Parameter Operation 
[7:6] - 00b = Set volatile version of data 1 bits 5:0 and data 2 
01b = Set non-volatile version of data 1 bits 5:0 and data 2 
10b = Copy non-volatile setting to volatile setting (restore default). 
11b = reserved 
Terminal mode options 
[5]- Ob = disable line editing 
1b = enable line editing 
[4]- reserved 
[3:2] - delete control (only applies when line editing is enabled) 
00b = BMC outputs a <del> character when <bksp> or <del> is received 
01b = BMC outputs a <bksp><sp><bksp> sequence when <bksp> or <del> is 
received 
[1]- Ob = no echo 
1b = echo (BMC echoes characters it receives) 
[0] - Ob = disable handshake (See 14.7.7, Terminal Mode Packet Handshake) 
1b = enable handshake 
data 2 - newline sequences 
[7:4] - output newline sequence (BMC to console). Selects what characters the BMC 
uses as a <newline> sequence when the BMC writes a line to the console in 
Terminal Mode. 
Oh = no termination sequence 
th = <cr-If> (default) 
2h = <NULL> 
3h = <CR> 
4h = <LF-CR> 
5h = <LF> 
all other = reserved. 
[3:0] - input newline sequence (Console to BMC). Selects what characters the console 
uses as the <newline> sequence when writing to the BMC in Terminal Mode. 
Oh = reserved 
1h = <cr> (default) 
2h = <NULL> 
all other = reserved. 
PPP Protocol Options 30 | data 1 - Snoop Control 


7:3] - reserved 
[2]- System Negotiation Snooping 
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Parameter Data (non-volatile unless otherwise noted)" 
1b = BMC snoops system’s PPP negotiation (optional) 
Ob = BMC doesn't snoop system’s PPP negotiation 
[1:0] - Snoop ACCM Control 
OOb = BMC uses Transmit ACCM when snooping (mandatory if connection mode 
Auto-detect is supported) 
01b = BMC uses Snoop ACCM when snooping (mandatory if connection mode 
Auto-detect is supported) 
10b = reserved 
11b = reserved 


data 2 - Negotiation Control 
[7:6] - reserved 
[5:4] - Negotiation Control 
00b = BMC Negotiates link parameters (runs LCP) on initial connection and 
whenever mux becomes switched to BMC and a connection is present. 
01b = BMC Negotiates link parameters on initial connection only. Upon a mux 
switch to the BMC, the BMC continues using the parameters it had originally 
negotiated. If BMC did not do the negotiation, BMC uses pre-configured 
settings, following - unless system negotiation snooping is enabled, in which 
case BMC uses system parameters. 
10b = BMC never negotiates link parameters. BMC always uses pre-configured 
settings unless system negotiation snooping is enabled, in which case BMC 
uses system parameters. 
11b = (optional) 
[3] - reserved 


Pre-configured link settings 

[2] - 1b= BMC uses Transmit ACCM to filter received characters 

Ob = BMC assumes all control characters 00h-1Fh are escaped 

[1] - 1b= BMC transmits with Address and Control Field Compression 
Ob = BMC transmits without Address and Control Field Compression 
[0] - 1b= BMC transmits with Protocol Field Compression 

Ob = BMC transmits without Protocol Field Compression 


data 3 - Negotiation Configuration. This parameter selects what the BMC negotiates for 
when it runs LCP. 

[7:5] - reserved 

[4:3] - BMC PPP IP Address Negotiation. 

00b = Request PPP IP Address Assignment. BMC issues an IPCP Configure- 

Request for IPCP Option 3 “IP Address”. The BMC uses the PPP Account 
#1’s IP Address parameter (below) as the initial value in the request. If the 
remote console responds with a different address in a Configure-Nak for 
option 3, the BMC shall accept that IP Address value and use it as its PPP IP 
Address. 


Per [RFC1332], an address of 00.00.00.00 indicates a request to the peer 
(remote console) to provide the IP Address. If option 3 is rejected, the BMC 
shall use the PPP Account #1’s IP Address parameter setting for any IP 
Protocol (0021h) packets it sends to the remote console. The BMC may 
silently discard any IP Protocol packets addressed to an IP Address other 
than the negotiated PPP IP Address. 


01b = Request Fixed PPP IP Address. This is the same as negotiation option 00b 
“Request PPP IP Address Assignment” except that the BMC will reject any 
alternative address offered by the remote console, and will continue to 
request PPP Account #1’s IP Address as the IP Address it will use. 


10b = No PPP IP Address Negotiation. The BMC does not issue a Configure- 
Request to request a PPP IP Address. If this option is selected, the BMC shall 
accept any IP Protocol (0021h) message delivered to the Primary or 
Secondary RMCP Port addresses. The BMC shall use the PPP IP Address 
parameter setting for any IP Packets it generates. 


11b = reserved. 
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Parameter # Parameter Data (non-volatile unless otherwise noted)! 
[2]- 1b = Enable ACCM negotiation 
Ob = Disable ACCM negotiation (also use Ob if this option not supported) 
[1]- 1b = Enable Address and Control Field Compression 
Ob = Disable Address and Control Field Compression (also use Ob if this option not 
supported) 
[0]- 1b = Enable Protocol Field Compression 
Ob = Disable Protocol Field Compression(also use Ob if this option not supported) 
PPP Primary RMCP Port 31 data 1:2 - Primary RMCP Port Number, LS-byte first. 
Number (optional) Default = 26Fh (RMCP ‘Aux Bus Shunt’ port) 
PPP Secondary RMCP 32 data 1:2 - Secondary Port Number, LS-byte first. 
Port Number (optional) Default = 298h (RMCP ‘Secure Aux Bus’ port) 
PPP Link Authentication 33 data 1 - Link Authentication Type. This configuration option selects whether the PPP Link 
itself is authenticated or not. Used with IPMI Messaging in PPP Mode, this 
parameter selects which type of Link Authentication will be used when a 
remote console initiates the connection and the BMC acts as the 
‘authenticator’. 

For PAP, CHAP, and MS-CHAP: The usernames (peer names / peer IDs) and 
passwords (peer password) used for Link Authentication for IPMI Messaging 
are obtained from users for which the “Enable User for Link Authentication” bit 
has been set using the Set User Access command. 

For PAP: The ’peer ID’ field in the Authenticate Request from the remote console is 
expected to hold the username, and the password field the password. The 
BMC uses the peer ID field contents. Assuming the user is appropriately 
enabled for the channel, the BMC then compares the stored password with the 
password that was submitted in the Authenticate Request. 

For CHAP and MS-CHAP v1 & v2: The remote console responds to a challenge 
generated by the BMC. The BMC takes the name field from that response and 
uses it as the username to look up the user and password information from the 
user configuration information. Assuming the user is appropriately enabled for 
the channel, the BMC will then use that password to verify the response. If the 
name field is empty, the BMC attempts to look up the password using the Null 
username. Note that the BMC also inserts the CHAP Name (parameter 34) in 
the name field of the challenge it generates. 

[7:4] - reserved 
[3:0] -PPP Link Authentication protocol 
Oh = none 
1h = CHAP 
2h = PAP [RFC1334] 
3h = MS-CHAP v1 [RFC2433] BMC requires challenge response to be in Windows 
NT format. 

4h = MS-CHAP v1 [RFC2433] BMC generates challenge response in LAN Manager 
format. (LAN Manager format is deprecated in RFC 2433, this option is only 
provided for implementations that may wish to support connecting to older 
systems that do not support Windows NT format.) 

5h = MS-CHAP v2 [RFC2759] 

CHAP Name 34 data 1:16 - Null terminated ASCII string for the “system name” used to represent the 
(required if CHAP BMC when it emits a challenge during CHAP. This is only used when dialing in to the 
supported) BMC. If this parameter is provided, it will also be used by MS-CHAP v1 & v2. 
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PPP ACCM 
(optional) 
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Parameter Data (non-volatile unless otherwise noted)! 

data 1:4 - Receive ACCM, MS-byte first. (Is-bit of Is-byte corresponds to character OOh, 
ms-bit of ms-byte corresponds to character 1Fh). The BMC uses this field as part of link 
negotiation. A 1b in a bit position identifies a character the must be escaped in order to be 
accepted by the BMC. 


The BMC will ignore any corresponding characters that are not escaped. Note that per 
[RFC1662] the BMC is required to accept all escaped characters regardless of whether 
they're part of the set that the BMC required to be escaped. 

(If XON/XOFF is used, be sure to include the XON/XOFF characters in the ACCM.) 


If ACCM Negotiation is not enabled (or this parameter is not supported), the BMC will 
require that all control characters (00h-1Fh) be escaped. 


data 5:8 - Transmit ACCM, MS-byte first (Is-bit of Is-byte corresponds to character 00h, 
ms-bit of ms-byte corresponds to character 1Fh). H ACCM Negotiation is enabled, and 
this field is supported, this field will determine which characters the BMC will always 
transmit with escaping. Characters that match the value for the PPP flag character (7Eh) 
and escape character (7Dh) are always escaped when encountered in the data, so the 
values in the corresponding bit positions are ‘don’t care’. l.e. if you set this field to all O's, 
the 7Eh and 7Dh will still be escaped before being transmitted. 


If ACCM Negotiation is enabled, but this field is not supported, the BMC will negotiate to 
transmit all control characters (00h-1Fh) with escaping. 


If ACCM Negotiation is not enabled, the BMC will transmit all control characters (00h-1Fh) 
with escaping. 


PPP Snoop ACCM 
(optional. Required if 
Connection Mode Auto- 
detect is supported for 
PPP mode) 
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data 1:4 - Snoop Receive ACCM, MS-byte first. (Is-bit of Is-byte corresponds to character 
00h, ms-bit of ms-byte corresponds to character 1Fh). A 1b in a bit position identifies a 
character the must be escaped in order to be accepted by the BMC. The BMC can be 
directed to use this receive ACCM when snooping for a PPP Packet for Connection Mode 
Auto-detect. This ACCM is used while snooping when the mux is switched over to the 
system. 


Number of PPP Accounts 
(READ ONLY) 
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data 1 - Number of non-volatile destination IP Addresses for this channel. Account 0 is 
always present and is typically used as a volatile destination that is used with the Alert 
Immediate command. Account 1 is used for IPMI Messaging via PPP. 
[7:4]- reserved. 
[3:0] - Oh = PPP Alerting and Callback are not supported. 

9h to Fh = reserved. 


PPP Account Dial String 
Selector 
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data 1 - set selector = account set selector. 
data 2 - Dial String Selector. Selects which dial string from the Destination Dial Strings to 
use for calling the given PPP account. 


PPP Account IP 
Addresses, BMC IP 
Address 
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This is the IPv4 Address used to connect to a PPP Server for dial-out alerting or callback. 
This value will be assumed to be the IP Address of the PPP Server unless the PPP 
Server requests a different address by negotiating IPCP Option 3 (IP Address). The BMC 
will offer this address to the PPP Server if the PPP Server passes 00.00.00.00 as the 
requested IP Address when negotiating IPCP option 3. Otherwise, the BMC will accept 
the IP Address requested by the PPP Server. 


Account 0 is always present and is typically used as a volatile destination that is used with 
the Alert Immediate command. 


Account 1 holds the IP Address used for IPMI Messaging via PPP (the BMC’s IP 
Address) instead of a PPP Server's IP Address. It is also used as the BMC’s IP Address 
when connecting to a remote system for callback or PPP Alerts. The Account 1 IP 
Address is handled according to the PPP Protocol Options parameter, above. 


data 1 - set selector = account set selector. 
data 2:5 - IP Address. MS-byte first. 0000 0000h = unspecified. 
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PPP Account User Names 
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Parameter Data (non-volatile unless otherwise noted)! 
This parameter holds the username data for dial-out alerting or callback. 


For MS-CHAP: The BMC will prefix the PPP Account Domain (parameter 41) to this 
parameter an use the result in the name field of the response to the challenge. 
The challenge response is based on the specified algorithm and the PPP 
Account User Password (parameter #42) for the account. 


For PAP and CHAP: The BMC uses this parameter to populate the peer ID when 
generating a PAP authentication request, or in the name field of the response 
to a CHAP challenge. The challenge is signed using the specified algorithm 
and the PPP Account User Password (parameter #42) for the account. 


data 1 - set selector = account set selector. 
data 2:N - User Name data. ASCII string. 16 characters, max. Null terminated if fewer 
than 16 characters are used. 


PPP Account User 
Domains 


41 


Required for dial-out alerting using MS-CHAP v1 or v2. If string is non-empty it will be 

transmitted as a prefix to the user name. Per [RFC2433] & [RFC2759] the domain and 

user name are separated by a backslash 'V character. This character is not automatically 

added by the BMC and should be entered as the last character of the domain. 

data 1 - set selector = account set selector. 

data 2:N - User Domain data. ASCII string. 16 characters, max. Null terminated if fewer 
than 16 characters are used. 


PPP Account User 
Passwords 
(Write Only) 
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The PPP Account parameters (selected by the account set selector value) are used for 
connecting to remote systems for dial-out alerting or callback using PPP/UDP mode. 


Note, the usernames (peer names) and passwords used for Link Authentication for ‘call 
in’ IPMI Messaging are obtained from users for which the “Enable User for Link 
Authentication” bit has been set using the Set User Access command. 


data 1 - set selector = account set selector. 
data 2:N - password data. ASCII string. 16 characters max. Null terminated if fewer than 
16 characters are used. 


PPP Account 
Authentication Settings 
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These parameters are used for ‘dial-out’ connections. 


data 1 - set selector = account set selector 
data 2 - Link Authentication Type 
[7:4] - reserved 
[3:0] -PPP Link Authentication protocol. 
Oh = none (Link Authentication not used) 
1h = CHAP 
2h = PAP 
3h = MS-CHAP v1 [RFC2433] BMC generates challenge response in Windows NT 
format 
4h = MS-CHAP v1 [RFC2433] BMC generates challenge response in LAN Manager 
format. (LAN Manager format is deprecated in RFC 2433, this option is only 
provided for implementations that may connect and send alerts to older 
systems) 
5h = MS-CHAP v2 [RFC2759] 


PPP Account Connection 
Hold Times 
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Minimum number of seconds that the call to the given account will be held prior to 
automatically hanging up the call. Note the connection will only stay open for this time if 
no other alert or action needs to call a different location or use the channel. Note that an 
implementation is allowed to terminate the connection on system resets, power on/off 
transitions, and power cycles. 

data 1 - set selector = account set selector 

data 2 - connection hold time in seconds. 1-based. 


PPP UDP Proxy IP 
Header data 
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data 1:4 - Source IP Address. MS-byte first. 
data 5:8 - Destination IP Address. MS-byte first. 


PPP UDP Proxy Transmit 
Buffer Size 
(READ ONLY) 
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data 1:2 - Transmit buffer size in bytes. 1-based. 
This parameter is used to return the size of the PPP UDP Proxy Data transmit buffer. 
0000h if PPP UDP Proxy not supported on given channel. 


PPP UDP Proxy Receive 
Buffer Size 
(READ ONLY) 
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data 1:2 - Receive buffer size in bytes. 1-based. 
This parameter is used to return the size of the PPP UDP Proxy Data transmit buffer. 
0000h if PPP UDP Proxy not supported on given channel. 
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Parameter # Parameter Data (non-volatile unless otherwise noted)! 
PPP Remote Console IP 48 data 1:4 - IP Address to offer remote peer if it requests the BMC to provide it an address 
Address as part of IPCP Negotiation. MS-byte first. 
(optional)! 
System Phone Number 49 This parameter can be used to store an ASCII string representing the ‘dial in’ number for 
(optional) this channel. This can enable an application such as a LAN remote console to retrieve the 
phone number for access when a LAN connection to the managed system becomes 
unavailable. 
data 1 - block number to set, 1 based. 
Blocks are 16-bytes. At least two blocks are required per number string, supporting a 
dial string of 31 characters plus terminator. 
data 2:N - Dial string data. Null terminated ASCII string. 
Bit Rate Support 50 | This parameter returns a read-only bitfield indicating which bit rates are supported for this 
(READ ONLY, optional) ee 
data 1 - Bit Rate Support 
[7:6] - reserved 
[4]- 115.2 kbps 
[3]- 57.6 kbps 
[2]- 38.4 kbps 
[1] - 19.2 kbps (required) 
[0] - 9600 bps 
System Serial Port 51 This parameter can be used to tell which serial controller channel is connected to a given 


Association (optional) 


(This parameter is allowed 
to be READ ONLY for 
implementations where 
the serial port 
configuration for IPMI is 
fixed) 


physical connector. It can also indicate whether that serial connector is used with Serial 
Port Sharing, used for IPMI over Serial 


data 1 - set selector = Serial Port Association Entry. 0-based. The set selector is only 
required to cover entries for serial connectors and/or serial channels that are used with 
IPMI. 


data 2 - serial connector number (A number for the physical connector. The choice of this 
number is implementation specific. For example, connector ‘1’ may correspond to a 
connector on the rear of a chassis for one system, and an internal header on another.) 
[7:4] - IPMI channel number (when connector is used for IPMI over serial) 
Oh = connector is not used with IPMI over Serial 
[3:0] - serial connector number 
Oh = no connector (e.g. when serial controller channel is used with IPMI SOL but 
is not shared with a serial connector) 


data 3 - serial controller channel number (a number for the system serial controller that is 
presently connected to the connector. The choice of this number is implementation 
specific.) 


[7] - serial controller channel is used with IPMI Serial Port Sharing (note: if this bit is 
1b then bits [7:4] of data 2 must hold a valid IPMI channel number.) 
[6] - serial controller channel is used with IPMI SOL 


[5:4]- reserved 

[3:0] - serial controller channel number 
Oh = no channel. (e.g. when a serial connector is just used for IPMI over Serial, 
and is not shared with the system) 
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Parameter 
System Connector Names 
(optional) 
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Parameter Data (non-volatile unless otherwise noted)" 


This parameter can be used to store strings for the serial connector names associated 
with the system serial association entries described in parameter 51. 


data 1 - set selector. O-based. This matches up with the set selector for parameter 51. 


data 2:17 - serial connector name or label. It is recommended that this match up with the 
connector labeling on the chassis or system board. The first byte of this data indicates the 
encoding of the string, as follows: 
string data 1: 
[7:4] - reserved 
[3:0] - encoding 
Oh = ASCII+LATIN 1. String is null terminated with OOh. 
th = UTF-8. Is-byte first. String is null terminated with 0000h. 
2h = UNICODE. Is-byte first. String is null terminated with 0000h. 
all other = reserved. 


System Serial Channel 
Names 


(optional) 
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This parameter can be used to store a string for the serial controller channel names 
associated with the system serial association entries described in parameter 51. 


data 1 - set selector. O-based. This matches up with the set selector for parameter 51. 


data 2:17 - serial channel name or label. The first byte of this data indicates the 
encoding of the string, as follows: 
string data 1: 
[7:4] - reserved 
[3:0] - encoding 
Oh = ASCII+LATIN 1. String is null terminated with 00h. 
1h = UTF-8. Is-byte first. String is null terminated with 0000h. 
2h = UNICODE. Is-byte first. String is null terminated with 0000h. 
all other = reserved. 
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Parameter 


Bad Password Threshold 
(optional) 
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Parameter Data (non-volatile unless otherwise noted)" 

Sets/Gets the Bad Password Threshold. If implemented and non-zero, this value 
determines the number of sequential bad passwords that will be allowed to be entered for 
the identified user before the user is automatically disabled from access on the channel. 
For example, a value of 3 indicates that 3 sequential attempts are allowed for the given 
username on the particular channel. If the password for the third attempt is not correct, 
the user will be disabled for the channel. If this value is zero (00h) then there is no limit on 
bad passwords. 


The effect of the disable is the same as if a Set User Access command were used to 
remove the user's access from the channel. 


Bad password attempts are tracked according to individual username on a per channel 
basis. (Thus, a given username may be disabled on one channel, but still enabled on 
another) Bad password attempts are not counted if integrity check or other session 
parameters, such as session ID, sequence number, etc. are invalid. That is, bad 
password attempts are not counted if there are any other errors that would have caused 
the login attempt to be rejected even if the password was valid. The count of bad 


password attempts is retained as long as the BMC remains powered and is not 
reinitialized. 


Counting automatically starts over (is reset) under any one of the following conditions: 
a) a valid password is received on any of the allowed attempts 

b) the Attempt Count Reset Interval expires 

c) the user is re-enabled using the Set User Access command 

d) the user is automatically re-enabled when the User Lockout Interval expires. 

e) the Bad Threshold number parameter value is re-written or changed 


The Set User Access command is used to re-enable the user for the Channel. 
byte 1 
7:1] - reserved 
0] -Ob = do not generate an event message when the user is disabled. 
1b = generate a Session Audit sensor "Invalid password disable" event message. 
byte 2 
7:0 - Bad Password Threshold number. 


byte 3:4 
15:0 - Attempt Count Reset Interval. The interval, in tens of seconds, for which the 
accumulated count of bad password attempts is retained before being 
automatically reset to zero. The interval starts with the most recent bad 
password attempt for the given username on the channel. This interval is 
allowed to reset if a BMC power cycles or re-initialization occurs while the 
interval is being counted. 
0000h = Attempt Count Reset Interval is disabled. The count of bad password 
attempts is retained as long as the BMC remains powered and is not 
reinitialized. 


byte 5:6 
15:0 - User Lockout Interval. The interval, in tens of seconds, that the user will remain 
disabled after being disabled because the Bad Password Threshold number 
was reached. The user is automatically re-enabled when the interval expires. 
Note that this requires the BMC implementation to track that the user was 
disabled because of a Bad Password Threshold. This interval is allowed to be 
restarted if a BMC power cycle or re-initialization occurs while the interval is 
being counted. Note that this requires an internal non-volatile setting to be 
maintained that tracks when a particular user has been temporarily disabled 
due to the Bad Password Threshold. This is required to distinguish a user that 
was disabled automatically from a user that is intentionally disabled using the 
Set User Access command. 
0000h = User Lockout Interval is disabled. If a user was automatically disabled 
due to the Bad Password threshold, the user will remain disabled 
until re-enabled via the Set User Access command. 


OEM Parameters 


192: 
255 


This range is available for special OEM configuration parameters. The OEM is identified 
according to the Manufacturer ID field returned by the Get Device ID command. 


1. Choice of system manufacturing defaults is left to the system manufacturer unless otherwise specified. 
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These settings are also copied from the corresponding non-volatile values whenever the system is powered up or hard 
reset. 

Optional but recommended if [MSVT] is implemented in conjunction with IPMI serial port sharing on the same serial 
interface. 

Optional but recommended if PPP supported. 

Per [MSVT] The BMC should put out an <ESC>* to the remote console after being switched by the <ESC>( sequence 
and after powering up/waking the system using the <ESC>* sequence. Refer to [MSVT] for timing requirements. 
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25.3 Set Serial/Modem Mux Command 


This command is used to force or request the selected serial mux to connect the serial connector to the baseboard 


serial port or the BMC serial port. The command also returns the present setting of the mux. 


Request Data 


Response Data 
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Table 25-, Set Serial/Modem Mux Command 

byte data field 
Channel number. This must correspond to the channel number that the 
desired serial/modem mux is on. 
[7:4] - reserved 
[3:0] - Channel number. 
Mux setting <VOLATILE> The BMC can override these settings on power 
down, power on, and system resets, and change it during system operation 
when a serial/modem connection is activated or deactivated. 


Otherwise, the ‘mux block’ settings are set back to ‘allowed’ on system power 
up, power down, power cycles, and resets except when those actions are 
initiated by the Chassis Control command. This enables a remote console to 
use the ‘block’ settings to keep connected to the BMC after causing a reset or 
power state change using the Chassis Control command. 


The BMC power-on default (i.e. when the BMC first gets powered/initialized) is 
based on the Access Mode setting for the channel (See Table 14-, Serial Port 
Sharing Access Characteristics). 


The blocking of ‘switch requests’ and ‘switch forces’ only affects the operation 
of the Set Serial/Modem Mux command. Switching caused by other 
mechanisms such as snooping and changes to system or connection states 
are not blocked. 


[7:4] - reserved 

[3:0] - Oh = get present mux setting/status only 
1h = request switch of mux to system 
2h = request switch of mux to BMC 
3h = force switch of mux to system 
4h = force switch of mux to BMC 
5h = block requests to switch mux to system 
6h = allow requests to switch mux to system 
7h = block requests to switch mux to BMC 
8h = allow requests to switch mux to BMC 


Lë Completion Code 


Mux setting. This returns the present state of the mux and the mux change 
bits from the last Set Serial/Modem Mux command. 


switch request enable settings 

[7]- 0b = requests to switch mux to system are allowed 

1b = requests to switch mux to system are blocked 

[6]- Ob = requests to switch mux to BMC are allowed 

1b = requests to switch mux to BMC are blocked 

switch status 

[5:4] - reserved 

[3] - Ob = no alert presently in progress 

1b = alert in progress on channel 

[2] - Ob = no IPMI or OEM messaging presently active on channel 

1b = IPMI or OEM messaging session active on channel 

Ob = request was rejected 

1b = request was accepted (see note, below) or switch was forced 

present mux setting 
Ob = mux is set to system (system can transmit and receive) 
1b = mux is set to BMC (BMC can transmit. System can neither 

transmit nor receive) 

: Bit 1 will immediately indicate whether the request was accepted. 
However, if ‘mux switch acknowledge’ is enabled, it may take seconds 
before the actual switch occurs. Software that needs to confirm a 
change of the present mux setting must poll the ‘present mux setting’ 
bit until it changes to the new state. 
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25.4 Get TAP Response Codes Command 


This command returns the values for up to the last five TAP response codes as an aid to verifying TAP settings. 
The values are volatile and are not guaranteed to be retained across system or management controllers resets or 
power on/off changes. The values are automatically cleared to ‘0’, ‘0’, ‘0’ at the start of a TAP page. The 
command is provided to aid in verifying and debugging the TAP configuration settings. 


Table 25-, Get TAP Response Codes Command 
byte data field 


Request Data 1 Channel number. 
[7:4] - reserved 
[3:0] - Channel number. 


Response Data Completion Code 
Most recent (last received) 3-character ASCII response code. MS-char. first. 


Second to last code. 
Third. 

Fourth. 

Fifth. 


25.5 Set PPP UDP Proxy Transmit Data Command 


This command is used to load data into the PPP UDP Proxy transmit data buffer. This data is expected to consist 
of UDP Packet Data starting with the first UDP data byte (byte following UDP checksum) through the last UDP 
data byte. The BMC fills in the remaining PPP and IP/UDP header information, and takes care of framing and 
escaping for delivering the data over PPP per [RFC1662]. The BMC does not verify the correctness of the data. 


Table 25-, Set PPP UDP Proxy Transmit Data Command 
byte data field 


Request Data 1 Channel number. 
[7:4] - reserved 
[3:0] - Channel number. 


3:18 | Block Data. 
16-byte block of packet data to set. Note the management controller does not 
check to see that the block is filled. All writes start at a 16-byte boundary in 
the buffer specified by the block number. If fewer than 16-bytes are sent, the 
BMC will not overwrite any prior data remaining in the block. 


Response Data Completion Code 


25.6 Get PPP UDP Proxy Transmit Data Command 


This command is used to retrieve data that has been written into the PPP UDP Proxy transmit data buffer. The 
command is primarily to aid in the test and debug of software that uses the PPP UDP Proxy capability. 


Table 25-, Get PPP UDP Proxy Transmit Data Command 
byte data field 


Request Data 1 Channel number. 
[7:4] - reserved 
[3:0] - Channel number 


Block number to get. 1-based. 
Response Data Completion Code 


2:17 | Block Data. Note, the BMC always returns 16-bytes of data, even if fewer data 
bytes were written to the specified block. 
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25.7 Send PPP UDP Proxy Packet Command 


This command is used to initiate the transmission of the PPP UDP Proxy Packet using the data stored in the PPP 
UDP Proxy transmit data buffer. 


Table 25-, Send PPP UDP Proxy Packet Command 
byte data field 


Request Data 1 Channel number. 
[7:4] - reserved 
[3:0] - Channel number. 


UDP Source Port Number. LS-byte first. 


UDP Destination Port Number. LS-byte first. 


Source IP Address. MS-byte first. 00 00 00 00h = Use PPP IP Address 
associated with this channel. (See Table 25-, Serial/Modem Configuration 
Parameters) 


Destination IP Address. MS-byte first. MS-byte first. The Get Session Info 
command can be used to look this up for a given session. Software using the 
Send PPP UDP Proxy command will usually get a Session ID or Session 
Handle from the Boot Options or from a message retrieved via a Get Message 
command. 


Number of bytes to send. 1-based. 


Response Data Completion Code. Generic, plus the following command specific. 
80h = PPP Link is not up 
81h = IP Protocol is not up 


25.8 Get PPP UDP Proxy Receive Data Command 


This command is used to retrieve data from the PPP UDP Proxy receive data buffer. The data buffer holds the 
complete received PPP IP Packet, from the byte following protocol field up to, but excluding, the FCS field. The 
BMC handles PPP Framing and extracting the encapsulated IP data, including checking the PPP Header 
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information and the FCS, and translating any escaped data in the packet. The BMC does not check the correctness 
of the encapsulated IP data. The packet is silently discarded if a bad FCS or partial packet is received. 


Table 25-, Get PPP UDP Proxy Receive Data Command 
byte data field 


Request Data Channel number. 
[7:4] - reserved 
[3:0] - Channel number. 
[7] - Clear Buffer 
1b = clear buffer after returning response to this command. 
Ob = don’t clear buffer after completing this command. 
[6:0] - Block Number. 1-based. 
000_0000b = Get received data length. 
Response Data Completion Code. 
80h = No packet data available. (Returned when a non-zero block number is 
used but there’s no packet data available.) 
If block number = 000_0000b: 


Number of received data bytes. 

0000h after buffer is emptied until a full packet received. This value can be 
polled to see when a new packet is available. Software must explicitly clear 
the buffer after completing the read of each packet. 


Received packets are volatile. The controller may discard packets on 
controller resets, system resets, system or controller power on/off changes, 
the enable/disable of the associated channel, or the enable/disable of PPP 
mode on the associated channel, on changes to the link up/down state, or 
changes to the IP protocol up/down state. 

If block number non-zero: 


Block Data. 
Note, the BMC implementation is allowed to always return a return a full 16- 
byte block of data, even if fewer bytes were received in the last block. 


25.9 Serial/Modem Connection Active (Ping) Command 


This command is also referred to as the “Serial/Modem Ping”. It is sent by the BMC to tell a remote console 
application whether the system or the BMC is connected to the serial connector before the remote console sends 
any messages. If Serial Port Sharing is implemented, this command is also sent out before a mux switch from 
BMC to the system occurs, and immediately after a switch from the system to the BMC occurs. Refer to /4.3, 
Serial/Modem Connection Active (Ping) Message for details about the operation of this command. 


When enabled, the Serial/Modem Connection Active message is sent out at a nominal rate of once every two 
seconds, +/- 10% for Basic Mode and Terminal Mode. The BMC is required to send it’s first Serial/Modem 
Connection Active message out within 100 milliseconds of the serial connection to the BMC being established. 
For PPP Mode, the Serial/Modem Connection Active message will only be sent out before a mux switch from 
BMC to the system occurs, and immediately after a switch from the system to the BMC occurs, 


When the BMC issues the Serial/Modem Connection Active command, it will typically be addressed to remote 
console software. Thus, for IPMI serial/modem and LAN connections the responder’s address byte should be set 
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to 81h, which is the software ID (SWID) for remote console software. See Section 5.5,Software IDs (SWIDs), for 
more information. 


Table 25-, Serial/Modem Connection Active Command 
byte data field 


Request Data Session state 
[7:4] - reserved 
[3:0] - session state 
Oh - No session active (password required) 
th - Session active (sent after mux switch to BMC or <ESC>( [if enabled] 


detected - and then periodically afterward) 
2h - Switching mux to system 
IPMI Version in hexadecimal, LSN first. 51h corresponds to IPMI 1.5. 


Response Data eS Completion Code 


25.10 Callback Command 


This command is used to initiate a callback to the selected destination. An error completion code will be returned 
if the specified destination has not been configured to be a callback destination for the selected channel. This 
callback is accomplished using IPMI commands. Note that there is also a PPP option to perform callback using 
CBCP. CBCP callback does not use this command. See 14.6.1, Callback Control Protocol (CBCP) Support. 


If the callback command is initiated over the same connection that the callback is to occur over, the BMC will 
deliver the response to the callback command, and if the Completion Code is 00h (OK) the BMC will terminate 
the session, hang-up the phone, and initiate the callback. 


Table 25-, Callback Command 
byte data field 
Request Data Channel number. (This value is required to select which configuration 
parameters are to be used for callback.) 
[7:4] - reserved 
[3:0] - Channel number 
Destination Selector 
Selects which alert destination the callback should go to. 
[7:4] - reserved 


[3:0] - destination selector. 0 = use volatile destination info. 1-Fh = non- 
volatile destination. 


Response Data Completion Code. Generic codes, plus following command-specific 
completion codes: 
81h = Callback rejected due to alert in progress on this channel. 
82h = Callback rejected due to IPMI messaging session active on the callback 
channel. 
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25.11 Set User Callback Options Command 


This command is used to configure the callback options associated with a specific user. Note that the options are 
also channel-specific. An implementation can allow three different callback numbers to be offered as part of the 
callback negotiation. 


Table 25-, Set User Callback Options Command 
byte data field 


Reguest Data User ID. (00h = reserved. 01h=Set password and enable/disabled User 1) 

7:6- reserved. 

5:0- User ID. 000000b, 000001b = reserved. (User ID 1 is permanently 
associated with User 1, the null user name). 

Channel Number 

[7:4] - reserved 

[3:0] - Channel number 

User callback capabilities 

[7:2] - reserved 

[1]- 1b = user enabled for CBCP callback 

[0]- 1b = user enabled for IPMI callback 

CBCP Negotiation Options. Used when user enabled for CBCP callback, and 

CBCP is globally enabled in the serial/modem configuration parameters. 

[7:4] - reserved. 

[3]- 1b = enable callback to one from list of possible numbers. Allow caller 
to pick one of a set of phone numbers offered by the BMC. 

[2]- 1b = enable user-specifiable callback number. Allow caller to specify 
number to be used for callback. 

[1]- 1b = enable pre-specified number. Allow caller to request that 
callback occur to a single, pre-specified number for the user. 

[0]- 1b = enable No Callback. Allow caller to request that callback not be 
used. 

Callback destination 1. This field holds a Destination Selector that picks which 

Destination Dial String from the serial/modem configuration parameters to use 

for callback. This selector is used when the ‘pre-specified number’ option is 

used. Otherwise, this is the first number in the list when the “caller selects one 

number from a list of numbers” option is used. 

FFh = unspecified. 


Note, if this field is set to FFh, the BMC should reject CBCP negotiation for 
the ‘pre-specified number’ option, even if it is enabled in the CBCP 
Negotiation Options field, above. 

Callback destination 2. This is the second number in the list when the “caller 
selects one number from a list of numbers” option is used. 

FFh = unspecified. 


Note, at least one destination must be specified in order for the ‘callback to 
one from a list of numbers’ option to be negotiated, even it that option is 
enabled in the CBCP Negotiation Options field, above. 

Callback destination 3. This is the third number in the list when the “caller 
selects one number from a list of numbers” option is used. 

FFh = unspecified. 


Note, at least one destination must be specified in order for the ‘callback to 
one from a list of numbers’ option to be negotiated, even it that option is 
enabled in the CBCP Negotiation Options field, above. 


Response Data Completion Code. 
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25.12 Get User Callback Options Command 


This command is used to return the present settings for the User Callback Options. 


Table 25-, Get User Callback Options Command 
byte data field 


Reguest Data User ID. (00h = reserved. O1h-Set password and enable/disabled User 1) 
[7:6] - reserved. 
[5:0] - User ID. 000000b, 000001b = reserved. (User ID 1 is permanently 
associated with User 1, the null user name). 


Channel Number 


Response Data 1 Completion Code. 
User callback capabilities 
[7:2] - reserved 
[1]- 1b = user enabled for CBCP callback 
[0]- 1b = user enabled for IPMI callback 
CBCP Negotiation Options. Used when user enabled for CBCP callback, and 
CBCP is globally enabled in the serial/modem configuration parameters. 
[7:4] - reserved. 
[3]- 1b = callback to one from list of possible numbers enabled 
[2]- 1b = user-specifiable callback number enabled. 
[1]- 1b = callback to pre-specified number enabled. 
[0]- 1b = No Callback enabled. Allow caller to negotiate that callback not 

be used. 

Callback destination 1. This field holds a Destination Selector that picks which 
Destination Dial String from the serial/modem configuration parameters to use 
for callback. This selector is used when the ‘pre-specified number’ option is 
used. Otherwise, this is the first number in the list when the “caller selects one 
number from a list of numbers” option is used. 
FFh = unspecified. 
Callback destination 2. This is the second number in the list when the “caller 
selects one number from a list of numbers” option is used. 
FFh = unspecified. 
Callback destination 3. This is the third number in the list when the “caller 
selects one number from a list of numbers” option is used. 
FFh = unspecified. 


25.13 Set Serial Routing Mux Command 


This optional command supports implementations where an add-in card can take over responsibility for Serial 
Port Sharing from the BMC. The command enables an add-in card or adjunct management controller to direct the 
BMC to route serial connections to the add-in or allow them to be handled by the BMC. Logically, this action can 
be viewed as controlling a hardware multiplexer (serial routing mux) that routes the serial signals between the 
BMC and the add-in, though this specification does not describe or require a particular hardware implementation 
for supporting this capability. The command also returns the present setting of the serial routing mux. 


For BMC implementations, the setting is volatile with respect to BMC initialization. The BMC ‘power on default’ 
shall be “BMC controlled”. Otherwise, the BMC must retain this setting across systems resets and power cycles as 
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long as the BMC remains powered (with the exception of actions such as BMC Cold Resets or firmware updates, 
where the setting is allowed to return to the power-on default). 


Request Data 


Response Data 


Table 25-, Set Serial Routing Mux Command 
byte data field 


Channel number. This must correspond to the channel number that the 
desired serial/modem routing mux is associated with. 

[7:4] - reserved 

[3:0] - Channel number. 

Serial Port Association entry 

This value matches up with the Serial Port Association Entry value used as 
the set selector for the System Serial Port Association parameter in the serial 
configuration parameters for the given channel. This enables support for 
implementations where different IPMI serial capabilities are associated with 
different ports or system serial controllers. For example, an implementation 
where SOL is associated with a different system serial controller than IPMI 
serial port sharing or IPMI over Serial. 

Mux setting <VOLATILE> The BMC can override these settings on power 
down, power on, and system resets, and change it during system operation 
when a serial/modem connection is activated or deactivated. 


[7:4] - reserved 

[3:0] - Oh = get present mux setting/status only 
1h = serial routing is BMC controlled 
2h = force switch of mux to route “ System to Add-In” 
3h = force switch of mux to route “Connector to System” 
4h = force switch of mux to route “Connector to Add-in” 


EE. Completion Code 


Mux setting. This returns the present state of the mux and the mux change 
bits from the last Set Mux Control command. 


present mux setting 

[7:4] - reserved 

[3:0] - Oh = reserved 
1h = routing under BMC control 
2h = routing set to “System to Add-in” 
3h = routing set to “Connector to System” 
4h = routing set to “Connector to Add-in” 
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26. SOL Commands 


The following commands are specific to the SOL Payload type. 


Table 26-, SOL Commands 


| Section | 

Command Defined O/M 
SOL Activating 26.1 OF! 
Set SOL Configuration Parameters 26.2 ON] 
Get SOL Configuration Parameters 26.3 ON] 


1. | Mandatory if the SOL Payload type is implemented. 


2. Mandatory if implementation uses Serial Port Sharing with SOL when 


activating SOL causes a serial session to be closed. 


26.1 SOL Activating Command 


This command provides a mechanism for the BMC to notify a remote application that a SOL payload is activating 
on another channel. The primary use for this command is in conjunction with Serial Port Sharing to notify an 
application that is connected to the system serial port that they have lost their connection because another 
application has activated SOL and the baseboard serial controller is now being used for SOL. 
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Request Data 


Response Data 


Table 26-, SOL Activating Command 
data field 


SOL Session State 
[7:4] - reserved 
[3:0] - Session State 
Oh = SOL Activating (Shared serial connection about to be lost because 
BMC is about to switch it over for SOL use) 


SOL Payload Instance 


SOL format version, major (SOL Payload Format version. See Table 13-, 


Payload Type Numbers. 


SOL format version, minor (SOL Payload Format version. See Table 13-, 
Payload Type Numbers. 


Completion Code 

The request message is a message that is asynchronously generated by the 
BMC. The BMC will not wait for a response from the remote console before 
dropping the serial connection to proceed with SOL, therefore the remote 
console does not need to respond to this command. 
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26.2 Set SOL Configuration Parameters Command 


This command is used for setting parameters such as the network addressing information required for SOL 
payload operation. Parameters can be volatile or non-volatile. Refer to Section 15.8, Volatile and Non-volatile 
SOL Configuration Parameters, for information on how these settings are handled for SOL payloads. 


Table 26-, Set SOL Configuration Parameters Command 
byte data field 


Request Data [7:4] - reserved 
[3:0] - Channel number. 
Parameter selector 


Configuration parameter data, per Table 26-, SOL Configuration Parameters 


Response Data Completion Code 
80h = parameter not supported. 
81h = attempt to set the ‘set in progress’ value (in parameter #0) when not in 
the ‘set complete’ state. (This completion code provides a way to 
recognize that another party has already ‘claimed’ the parameters) 
82h = attempt to write read-only parameter 
83h = attempt to read write-only parameter 


26.3 Get SOL Configuration Parameters Command 


This command is used for retrieving the configuration parameters from the Set SOL Configuration Parameters 
command. 


Table 26-, Get SOL Configuration Parameters Command 
byte data field 


Request Data [7] - Ob = get parameter 
1b = get parameter revision only. 
[6:4] - reserved 
[3:0] - Channel number. 
Parameter selector 
Set Selector. Selects a given set of parameters under a given Parameter 
selector value. 00h if parameter doesn’t use a Set Selector. 
Block Selector (00h if parameter does not require a block number) 


Response Data Completion Code. 
Generic codes, plus following command-specific completion code(s): 
80h = parameter not supported. 
[7:0] - Parameter revision. 
Format: MSN = present revision. LSN = oldest revision parameter is backward 
compatible with. 11h for parameters in this specification. 
The following data bytes are not returned when the ‘get parameter revision 
only’ bit is 1b. 
Configuration parameter data, per Table 26-, SOL Configuration Parameters 
If the rollback feature is implemented, the BMC makes a copy of the existing 
parameters when the ‘set in progress’ state becomes asserted (See the Set In 
Progress parameter #0). While the ‘set in progress’ state is active, the BMC 
will return data from this copy of the parameters, plus any uncommitted 
changes that were made to the data. Otherwise, the BMC returns parameter 
data from non-volatile storage. 
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Table 26-, SOL Configuration Parameters 
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Parameter # Parameter Data (non-volatile unless otherwise noted)!"! 
Set In Progress 0 data 1 This parameter is used to indicate when any of the following parameters 
(volatile) are being updated, and when the updates are completed. The bit is primarily 


provided to alert software than some other software or utility is in the process of 
making changes to the data. 
An implementation can also elect to provide a ‘rollback’ feature that uses this 
information to decide whether to ‘roll back’ to the previous configuration information, 
or to accept the configuration change. 
If used, the roll back shall restore all parameters to their previous state. Otherwise, 
the change shall take effect when the write occurs. 
[7:2] - reserved 
[1:0] - 00b = set complete. If a system reset or transition to powered down state 
occurs while ‘set in progress’ is active, the BMC will go to the ‘set 
complete’ state. If rollback is implemented, going directly to ‘set 
complete’ without first doing a ‘commit write’ will cause any pending 
write data to be discarded. 
01b = set in progress. This flag indicates that some utility or other software is 
presently doing writes to parameter data. It is a notification flag only, it 
is not a resource lock. The BMC does not provide any interlock 
mechanism that would prevent other software from writing parameter 
data while. 
10b = commit write (optional). This is only used if a rollback is implemented. 
The BMC will save the data that has been written since the last time 
the ‘set in progress’ and then go to the ‘set in progress’ state. An error 
completion code will be returned if this option is not supported. 
11b = reserved 
Byte 1: 
[7:1]: Reserved 


[0]: SOL Enable. 
Note, this controls whether the SOL payload type can be activated. Noter 
that whether an SOL stream can be established is also dependent on the 
Access Mode and Authentication settings for the corresponding LAN 
channel. The enabled/disabled state and access mode settings for the 
serial/modem channel have no effect on SOL. 


1b = enable SOL payload 
Ob = disable SOL payload 


SOL Enable 
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Parameter 
SOL Authentication 


Character Accumulate 
Interval & Character 
Send Threshold 


SOL Retry 


# 


3 


Parameter Data (non-volatile unless otherwise noted)" 
Byte 1: SOL Authentication Enable 
[7]: Force SOL Payload Encryption 
1b: Force encryption. If the Cipher Suite for the session supports encryption this 
setting will force the use of encryption for all SOL payload data. 


Ob: Encryption controlled by remote console. Whether SOL Packets are 
encrypted or not is selectable by the remote console at the time the payload 
is activated (using the Activate Payload command) and can be changed 
during operation via the Suspend/Resume Payload Encryption command. 


[6]: Force SOL Payload Authentication 
1b: Force Authentication. If the Cipher Suite for the session supportes 


authentication this setting will force the use of authentication on all SOL 
Payload data. 


Ob: Authentication controlled by remote software. Note that for the standard 
Cipher Suites, if encryption is used authentication must also be used. 
Therefore, while encryption is being used software will not be able to select 
using unauthenticated payloads. 

[5:4]: Reserved 


[3:0]: SOL Privilege Level. Sets the minimum operating privilege level that is required 
to be able to activate SOL using the Activate Payload command. 

Oh: reserved 

th: reserved 

2h: USER level 

3h: OPERATOR level 

4h: ADMINISTRATOR level 

5h: OEM Proprietary level 

all other: Reserved 
Byte 1: Character Accumulate Interval in 5 ms increments. 1-based. This sets the 
typical amount of time that the BMC will wait before transmitting a partial SOL 
character data packet. (Where a partial packet is defined as a packet that has fewer 


characters to transmit than the number of characters specified by the Send 
Threshold - see next field in this parameter). A packet will not be sent 


00h = reserved 


Byte 2: Character Send Threshold. 1-based. The BMC will automatically send an 
SOL character data packet containing this number of characters as soon as this 
number of characters (or greater) has been accepted from the baseboard serial 
controller into the BMC. This provides a mechanism to tune the buffer to reduce 
latency to when the first characters are received after an idle interval. In the 
degenerate case, setting this value to a ‘1’ would cause the BMC to send a packet as 
soon as the first character was received. 


This can be useful if the character accumulate interval is large. If the BMC is waiting 
for an acknowledge from the previous packet, it will ignore this threshold and 
continue to collect data until it has a full packet’s worth. 

Byte 1: Retry Count 

[7:3] - Reserved 


[2:0] - Retry count. 1-based. 0 = no retries after packet is transmitted. Packet will be 
dropped if no ACK/NACK received by time retries expire. 


Byte 2: Retry Interval. 1-based. Retry Interval in 10 ms increments. Sets the time that 
the BMC will wait before the first retry and the time between retries when sending 
SOL packets to the remote console. 


OOh: Retries sent back-to-back 
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Parameter 


SOL non-volatile bit 
rate 


(non-volatile) 


SOL volatile bit rate 
(volatile) 

SOL Payload Channel 
(optional, Read Only) 


SOL Payload Port 
Number 


(Read Only or 
Read/Write - see 
description) 


OEM Parameters 


7 


a 


Parameter Data (non-volatile unless otherwise noted)! 


This configuration parameter is not supported if the implementation does not have a 
BMC serial controller that can be potentially configured 


Serial communication with the BMC when SOL is activated always occurs using 8 
bits/character, no parity, 1 stop bit, and RTS/CTS (hardware) flow control. 


Note: If SOL is enabled for multiple LAN channels, the BMC uses the serial 
communication settings for the channel over which the Activate SOL command was 
initially received. The settings for other channels are ignored. 


Data 1 
[7:4] - Reserved 


[3:0] - Bit Rate. 1-5h = reserved. Support for bit rates other than 19.2 kbps is 
optional. The BMC must return an error completion if a requested bit rate is not 
supported. It is recommended that the parameter out-of-range (C9h) code be used 
for this situation. 


Oh: Use setting presently configured for IPMI over serial channel. The setting will 
be used even if the access mode for the serial channel is set to ‘disabled’. Note: 
IPMI specification can allow more than one serial channel. If serial port sharing is 
not implemented, this value is reserved. 

6h: 9600 bps 

7h: 19.2 kbps 

8h: 38.4 kbps 

9h: 57.6 kbps 

Ah: 115.2 kbps 

all other = reserved 


Set volatile version of SOL Serial Settings. Data follows that for the SOL non-volatile 
bit rate parameter. 


This parameter indicates which IPMI channel is being used for the communication 
parameters (e.g. IP address, MAC address) for the SOL Payload. Typically, these 
parameters will come from the same channel that the Activate Payload command for 
SOL was accepted over. 

This parameter is Read/Write when the implementation allows the port number over 
which the SOL payload can be activated to be configurable. Otherwise, it is a Read 
Only parameter. 


data 1:2 - Primary RMCP Port Number, LSByte first. 


This range is available for special OEM configuration parameters. The OEM is 
identified according to the Manufacturer ID field returned by the Get Device ID 
command. 
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27. BMC Watchdog Timer Commands 


The BMC implements a standardized ‘Watchdog Timer’ that can be used for a number of system timeout 
functions by system management software or by the BIOS. Setting a timeout value of ‘0’ allows the selected 
timeout action to occur immediately. This provides a standardized means for devices on the IPMB, such as 
Remote Management Cards, to perform emergency recovery actions. Refer to Appendix G - Command 
Assignments 


for the specification of the Network Function and Command (CMD) values and privilege levels for these 
commands. 


Table 27-, BMC Watchdog Timer Commands 


Section 
Command Defined O/M 


Reset Watchdog Timer 


Set Watchdog Timer 
Get Watchdog Timer 


27.1 Watchdog Timer Actions 


The following actions are available on expiration of the Watchdog Timer: 
e System Reset 
e System Power Off 
e System Power Cycle 
e — Pre-timeout Interrupt (OPTIONAL) 


The System Reset on timeout, System Power Off on timeout, and System Power Cycle on timeout action 
selections are mutually exclusive. The watchdog timer is stopped whenever the system is powered-down. A 
command must be sent to start the timer after the system powers up. 


27.2 Watchdog Timer Use Field and Expiration Flags 


The watchdog timer provides a ‘timer use’ field that indicates the current use assigned to the watchdog timer. The 
watchdog timer provides a corresponding set of ‘timer use expiration’ flags that are used to track the type of 
timeout(s) that had occurred. 


The timeout use expiration flags retain their state across system resets and power cycles, as long as the BMC 
remains powered. The flags are normally cleared solely by the ‘Set Watchdog Timer’ command; with the 
exception of the “don’t log” flag, which is cleared after every system hard reset or timer timeout. 


The Timer Use fields indicate: 

BIOS FRB2 timeout An FRB-2 (fault-resilient booting, level 2) timeout has occurred. This 
indicates that the last system reset or power cycle was due to the system 
timeout during POST, presumed to be caused by a failure or hang related to 
the bootstrap processor®. 


BIOS POST timeout In this mode, the timeout occurred while the watchdog timer was being used 
by the BIOS for some purpose other than FRB-2 or OS Load Watchdog. 
OS Load timeout The last reset or power cycle was caused by the timer being used to 


‘watchdog’ the interval from ‘boot’ to OS up and running. This mode requires 
system management software, or OS support. BIOS should clear this flag if it 
starts this timer during POST. 


6 In a multiprocessor system, the bootstrap processor is defined as the processor that, on system power-up or hard reset, is allowed 
to run and execute system initialization (BIOS POST) while the remaining processors are held in a idle state awaiting startup by 
the multiprocessing OS. 
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SMS ‘OS Watchdog’ timeout This indicates that the timer was being used by System Management 
Software. During run-time, System Management Software (SMS) starts the 
timer, then periodically resets it to keep it from expiring. This periodic action 
serves as a ‘heartbeat’ that indicates that the OS (or at least the SMS task) is 
still functioning. If SMS hangs, the timer expires and the BMC generates a 
system reset. When SMS enables the timer, it should make sure the ‘SMS’ bit 
is set to indicate that the timer is being used in its ‘OS Watchdog’ role. 

OEM Indicates that the timer was being used for an OEM-specific function. 


27.2.1 Using the Timer Use field and Expiration flags 


The software that sets the Timer Use field is responsible for managing the associated Timer Use Expiration flag. 
For example, if system management software sets the timer use to ‘SMS/OS Watchdog’, then that same system 
management software is responsible for acting on and clearing the associated Timer Use Expiration flag. 


In addition, software should only interpret or manage the expiration flags for watchdog timer uses that it set. For 
example, BIOS should not report watchdog timer expirations or clear the expiration flags for non-BIOS uses of 
the timer. This is to allow the software that did set the Timer Use to see that a matching expiration occurred. 


27.3 Watchdog Timer Event Logging 


By default, the BMC will automatically log the corresponding sensor-specific watchdog sensor event when a 
timer expiration occurs. A “don’t log” bit is provided to temporarily disable the automatic logging. The “don’t 
log” bit is automatically cleared (logging re-enabled) whenever a timer expiration occurs. 


27.4 Pre-timeout Interrupt 


The Watchdog Timer offers a ‘Pre-timeout Interrupt’ option. This option is enabled whenever the ‘Interrupt on 
timeout’ option is selected coincident with any of the other Watchdog Timer actions. 


If this option is enabled, the BMC generates the selected interrupt a fixed interval before the timer expires. This 
feature can be used to allow an interrupt handler to intercept the timeout event before it actually occurs. 


The default pre-timeout interrupt interval is one (1) second. 


The watchdog timeout action and the pre-timeout interrupt functions are individually enabled. Thus, the 
Watchdog Timer can be configured so that when it times out it provides just an interrupt, just the selected action, 
both an interrupt and selected action, or none. 


If the pre-timeout interval is set to zero, the pre-timeout action occurs concurrently with the timeout action. Note 
that if a power or reset action is selected with a pre-timeout interval of zero there is no guarantee that a pre- 
timeout interrupt handler would have time to execute, or to run to completion. 


27.4.1 Pre-timeout Interrupt Support Detection 


An application that wishes to use a particular pre-timeout interrupt can check for its support by issuing a Set 
Watchdog Timer command with the desired pre-timeout interrupt selection. If the controller does not return an 
error completion code, then a Get Watchdog Timer command should be issued to verify that the interrupt 
selection was accepted. 


While it can be assumed that a controller that accepts a given interrupt selection supports the associated 
interrupt, it is recommended that, if possible, an application also generate a test interrupt and verify that the 
interrupt occurs and the handler executes correctly. 
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27.4.2 BIOS Support for Watchdog Timer 


Ifa system ‘Warm Reset’ occurs, the watchdog timer may still be running while BIOS executes POST. 
Therefore, BIOS should take steps to stop or restart the watchdog timer early in POST. Otherwise, the timer 
may expire later during POST or after the OS has booted. 


27.5 Reset Watchdog Timer Command 


The Reset Watchdog Timer command is used for starting and restarting the Watchdog Timer from the initial 
countdown value that was specified in the Set Watchdog Timer command. 


If a pre-timeout interrupt has been configured, the Reset Watchdog Timer command will not restart the timer once 
the pre-timeout interrupt interval has been reached. The only way to stop the timer once it has reached this point is 
via the Set Watchdog Timer command. 


Table 27-, Reset Watchdog Timer Command 
byte data field 
Request Data 


Response Data Completion Code. Generic plus the following command-specific completion 
codes: 
80h = Attempt to start un-initialized watchdog. It is recommended that a 
BMC implementation return this error completion code to indicate to 
software that a Set Watchdog Timer command has not been issued 


to initialize the timer since the last system power on, reset, or BMC 
reset. Note that since many systems may initialize the watchdog timer 
during BIOS operation, this condition may only be seen by software if 
a BMC gets re-initialized during system operation (as might be the 
case if a firmware update occurred, for example). 


27.6 Set Watchdog Timer Command 


The Set Watchdog Timer command is used for initializing and configuring the watchdog timer. The command is 
also used for stopping the timer. 


If the timer is already running, the Set Watchdog Timer command stops the timer (unless the “don’t stop” bit is 
set) and clears the Watchdog pre-timeout interrupt flag (see Get Message Flags command). BMC hard resets, 
system hard resets, and the Cold Reset command also stop the timer and clear the flag. 


Byte | is used for selecting the timer use and configuring whether an event will be logged on expiration. 
Byte 2 is used for selecting the timeout action and pre-timeout interrupt type. 


Byte 3 sets the pre-timeout interval. If the interval is set to zero, the pre-timeout action occurs concurrently with 
the timeout action. 


Byte 4 is used for clearing the Timer Use Expiration flags. A bit set in byte 4 of this command clears the 
corresponding bit in byte 5 of the Get Watchdog Timer command. 


Bytes 5 and 6 hold the least significant and most significant bytes, respectively, of the countdown value. The 
Watchdog Timer decrement is one count/100 ms. The counter expires when the count reaches zero. If the counter 
is loaded with zero and the Reset Watchdog command is issued to start the timer, the associated timer events 
occur immediately. 
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E 27-, Set Watchdog Timer Command 
yte data field 


Timer Use 
[7] - 1b = don’t log 
[6] - 1b = don't stop timer on Set Watchdog Timer command (new for IPMI 
v1.5) new parameters take effect immediately. If timer is already 
running, countdown value will get set to given value and 
countdown will continue from that point. If timer is already 
stopped, it will remain stopped. If the pre-timeout interrupt bit is 
set, it will get cleared." 
Ob = timer stops automatically when Set Watchdog Timer command is 
received 
[5:3] - reserved 
[2:0] - timer use (logged on expiration when “don’t log” bit = Ob) 
000b = reserved 
001b = BIOS FRB2 
010b = BIOS/POST 
011b = OS Load 
100b = SMS/OS 
101b = OEM 
110b -111b =reserved 


Timer Actions 
[7]- reserved 
[6:4] - pre-timeout interrupt (logged on expiration when “don’t log” bit = Ob) 
000b = none 
001b SMI (optional) 
010b = NMI / Diagnostic Interrupt (optional) 
011b = Messaging Interrupt (this is the same interrupt as 
allocated to the messaging interface, if communications 
interrupts are supported for the system interface) 
= 
Få 


Request Data 


100b,111b = reserved 
[3]- reserved 
[2:0] - timeout action 
000b = no action 
001b = Hard Reset 
010b = Power Down 
011b = Power Cycle 
100b,111b = reserved 


Pre-timeout interval in seconds. ‘1’ based. 


Timer Use Expiration flags clear 

(Ob = leave alone, 1b = clear timer use expiration bit) 
[7]- reserved 

[6]- reserved 

[5]- OEM 

[4] - SMS/OS 

[3] - OS Load 

[2] - BIOS/POST 

[1] - BIOS FRB2 

ESE reserved 

Initial countdown value, Isbyte (100 ms/count) 


Initial countdown value, msbyte 
Response Data EE Completion Code 


Potential race conditions exist with implementations of this option. If the Set Watchdog Timer 
command is sent just before a pre-timeout interrupt or timeout is set to occur, the timeout 
could occur before the command is executed. To avoid this condition, it is recommended that 
software set this value no closer than 3 counts before the pre-timeout or timeout value is 
reached. 
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27.7 Get Watchdog Timer Command 


This command retrieves the current settings and present countdown of the watchdog timer. The Timer Use 
Expiration flags in byte 5 retain their states across system resets and system power cycles. With the exception of 
bit 6 in the Timer Use byte, the Timer Use Expiration flags are cleared using the Set Watchdog Timer command. 
They may also become cleared because of a loss of BMC power, firmware update, or other cause of BMC hard 
reset. Bit 6 of the Timer Use byte is automatically cleared to Ob whenever the timer times out, is stopped when the 
system is powered down, enters a sleep state, or is reset. 


Table 27-, Get Watchdog Timer Command 
byte 
ae 
2 


Request Data 
Response Data 


data field 


FEE 
Timer Use 
[7]- 1b =don’t log 
[6]- 1b = timer is started (running) 
Ob = timer is stopped 
[5:3] - reserved 
[2:0] - timer use (logged on expiration if don’t log bit = Ob) 
= reserved 
= BIOS FRB2 
= BIOS/POST 
= OS Load 
= SMS/OS 
= OEM 
110b,111b = reserved 
Timer Actions 
[7]- reserved 
[6:4] - pre-timeout interrupt 
000b = none 
001b = SMI (if implemented) 
010b = NMI / Diagnostic Interrupt (if implemented) 
011b = Messaging Interrupt (this would be the same interrupt as 
allocated to the messaging interface) 
100b,111b = reserved 
[3] - reserved 
[2:0] - timeout action 


000b = 
001b = 
010b = 
011b = 


no action 
Hard Reset 
Power Down 
Power Cycle 


100b,111b = reserved 


Timer Use Expiration flags (1b = timer expired while associated ‘use’ was 
selected.) 
reserved 
reserved 


BIOS/POST 
BIOS FRB2 
reserved 


Present countdown value, Isbyte. The initial countdown value and present 
countdown values should match immediately after the countdown is 
initialized via a Set Watchdog Timer command and after a Reset Watchdog 
Timer has been executed. 

Note that internal delays in the BMC may require software to delay up to 100 
ms before seeing the countdown value change and be reflected in the Get 
Watchdog Timer command. 


Present countdown value, msbyte 
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28. Chassis Commands 


The following chassis commands are specified for IPMI v1.5. These commands are primarily to provide 
standardized chassis status and control functions for Remote Management Cards and Remote Consoles that access 
the BMC. They can also be used for “emergency” management control functions by system management software. 
Refer to Appendix G - Command Assignments 


for the specification of the Network Function and Command (CMD) values and privilege levels for these 
commands. 


Table 28-, Chassis Commands 

[command | Demma | om | 

Command Defined O/M 

Get Chassis Status 28.2 MU] 
[Chassis Rest. o o T æo 
[Chassis enig] æs |o) 
[Set Front Panel Enabes | 25 | 0 | 
| Set Chassis Capabilities JL 287 | 0 | 
[Set Power Restore Poloy | 28 | 0 | 
[Set Power Gycle Inierval | 22 | 0 | 
[GetPOHGounter — [2614| 0 


1. These commands are mandatory for standalone server motherboards that 
include ACPI-based power control capabilities. 

2. Highly recommended. These commands should be supported on host systems 
that support remote reset and power on/off capabilities, since these commands 
enable remote coordination of the booting process with BIOS. 


28.1 Get Chassis Capabilities Command 


The Get Chassis Capabilities command returns information about which main chassis management functions are 
present on the IPMB (or virtual IPMB) and what addresses are used to access those functions. This command is 
used to find the devices that provide functions such as SEL, SDR, and ICMB Bridging so that they can be 
accessed via commands delivered via a physical or logical IPMB. Note that the command does not include a 
channel number for the individual functions, therefore all reported functions must be located on the primary 
IPMB. 


Refer to [ICMB] for additional information. 


The Chassis Capabilities information is non-volatile. There is no requirement that the information be 
configurable. The Chassis Device function in a peripheral chassis may be hardcoded with this information. For 
example, a system that implements the ICMB as an add-on bridge to a BMC will typically be able to have the 
well known address for the BMC (20h) hardcoded as the address for the Chassis SDR, SEL, and SM Devices, 
while the Chassis FRU Info Device address could be set with the chassis devices own address. 


An add-in device that serves as a bridge device that could be used in different vendors systems may want to 
provide a way for this information to be configured. The Set Chassis Capabilities command is one option for 
providing this. 
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Table 28-, Get Chassis Capabilities Command 
byte data field 
Request Data 


Response Data Completion Code 

Capabilities Flags 

[7:4] - reserved 

[3] - 1b = provides power interlock (IPMI 1.5) 

[2] - 1b = provides Diagnostic Interrupt (FP NMI) (IPMI 1.5) 

[1] - 1b = Provides “Front Panel Lockout” (this indicates that the chassis 
has capabilities to lock out external power control and reset 
button or front panel interfaces and/or detect tampering with 
those interfaces) 

[0] - 1b = Chassis provides intrusion (physical security) sensor 


Chassis FRU Info Device Address. 
Note: all IPMB addresses used in this command are have the 7-bit IC slave 
address as the most-significant 7-bits and the least significant bit set to Ob. 


00h = unspecified. 
Chassis SDR Device Address 


Chassis SEL Device Address 
Chassis System Management Device Address 


Chassis Bridge Device Address. Reports location of the ICMB bridge 
function. If this field is not provided, the address is assumed to be the BMC 
address (20h). Implementing this field is required when the Get Chassis 
Capabilities command is implemented by a BMC, and whenever the Chassis 
Bridge function is implemented at an address other than 20h. 
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28.2 Get Chassis Status Command 


The following command returns information regarding the high-level status of the system chassis and main power 
subsystem. 


Table 28-, Get Chassis Status Command 
byte data field 


Request Data | - | 
Response Data Completion Code 


Current Power State 
[7] - reserved 
[6:5] - power restore policy"! 
00b = chassis stays powered off after AC/mains returns 
01b = after AC returns, power is restored to the state that was in effect 
when AC/mains was lost 
10b = chassis always powers up after AC/mains returns 
11b = unknown 
power control fault 


1b = Controller attempted to turn system power on or off, but system 
did not enter desired state. 


power fault 
1b = fault detected in main power subsystem. 


1b = Interlock (chassis is presently shut down because a chassis 
panel interlock switch is active). (IPMI 1.5) 

Power overload 

1b = system shutdown because of power overload condition. 
Power is on 

1b = system power is on 

Ob = system power is off (soft-off S4/S5 or mechanical off) 

Last Power Event 

[7:5] - reserved 

[4]- 1b = last ‘Power is on’ state was entered via IPMI command 

[3] - 1b = last power down caused by power fault 

[2]- 1b = last power down caused by a power interlock being activated 

[1]- 1b = last power down caused by a Power overload 

[0]- 1b = AC failed 

Misc. Chassis State 

[7] - reserved 

[6] - 1b = Chassis Identify command and state info supported (Optional) 
Ob = Chassis Identify command support unspecified via this 

command. (The Get Command Support command, if 
implemented, would still indicate support for the Chassis Identify 
command) 

[5:4] - Chassis Identify State. Mandatory when bit [6] = 1b, reserved (return 
as 00b) otherwise. Returns the present chassis identify state. Refer to 
the Chassis Identify command for more info. 
00b = chassis identify state = Off 
01b = chassis identify state = Temporary (timed) On 
10b = chassis identify state = Indefinite On 
11b = reserved 

[3] - 1b = Cooling/fan fault detected 

[2]- 1b= Drive Fault 

[1]- 1b = Front Panel Lockout active (power off and reset via chassis 

push-buttons disabled.) 

[0] - 1b = Chassis intrusion active 
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Front Panel Button Capabilities and disable/enable status (Optional) 
(*Button” actually refers to the ability for the local user to be able to perform 
the specified functions via a pushbutton, switch, or other ‘front panel’ control 
built into the system chassis.) 
[7]- 1b = Standby (sleep) button disable allowed 
[6]- 1b = Diagnostic Interrupt button disable allowed 
[5] - 1b = Reset button disable allowed 
[4] - 1b = Power off button disable allowed (in the case there is a single 
combined power/standby (sleep) button, disabling power off also 
disables sleep requests via that button.) 
[3] - 1b = Standby (sleep) button disabled 
[2]- 1b = Diagnostic Interrupt button disabled 
[1]- 1b = Reset button disabled 
[0] - 1b = Power off button disabled (in the case there is a single combined 
power/standby (sleep) button, then this indicates that sleep 
requests via that button are also disabled.) 
1. In some installations, the chassis’ main power feed may be DC based. For 
example, -48V. In this case, the power restore policy for AC/mains refers to the 
loss and restoration of the DC main power feed. 


28.3 Chassis Control Command 
The following command provides a mechanism for providing power up, power down, and reset control. 


Table 28-, Chassis Control Command 
byte data field 


Request Data [7:4] - reserved 
[3:0] - chassis control?! 

Oh = power down. Force system into soft off (S4/S45) state. This is for 
‘emergency’ management power down actions. The command 
does not initiate a clean shut-down of the operating system prior to 
powering down the system. 

1h = power up. 

2h = power cycle (optional). This command provides a power off interval 
of at least 1 second following the deassertion of the system’s 
POWERGOOD status from the main power subsystem. It is 
recommended that no action occur if system power is off (S4/S5) 
when this action is selected, and that a D5h “Request parameter(s) 
not supported in present state.” error completion code be returned. 
Note that some implementations may cause a system power up if a 
power cycle operation is selected when system power is down. For 
consistency of operation, it is recommended that system 
management software first check the system power state before 
issuing a power cycle, and only issue the command if system 
power is ON or in a lower sleep state than S4/S5. 

3h = hard reset. In some implementations, the BMC may not know 
whether a reset will cause any particular effect and will pulse the 
system reset signal regardless of power state. If the implementation 
can tell that no action will occur if a reset is delivered in a given 
power state, then it is recommended (but still optional) that a D5h 
“Request parameter(s) not supported in present state.” error 
completion code be returned. 

4h = pulse Diagnostic Interrupt. (optional) Pulse a version of a diagnostic 
interrupt that goes directly to the processor(s). This is typically used 
to cause the operating system to do a diagnostic dump (OS 
dependent). The interrupt is commonly an NMI on IA-32 systems 
and an INIT on Intel® Itanium™ processor based systems. 

5h = Initiate a soft-shutdown of OS via ACPI by emulating a fatal 
overtemperature. (optional) 

all other = reserved 


Response Data Completion Code 


1. The implementation is allowed to return the completion code prior to performing 
the selected control action if necessary. 
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2. The command can also be used for compute blades or compute partition 
applications where the blades or partitions entities are emulating independent 
computer systems that implement IPMI. In these applications, the chassis power 
control aspects of the command are not required to be supported. Individual 
blades or computer partitions can elect to either not support the power on/off 
functions, can use them for power control of the blade/partition independent of 
the containing chassis, or may map them into a power control scheme for the 
overall chassis. For example, a scheme where chassis power will go off only 
after all blades within a chassis have been commanded into the ‘power off’ state. 


28.4 Chassis Reset Command 


This command was used with early versions of the ICMB. It has been superceded by the Chassis Control command 
and is not recommended for new implementations. Refer to [ICMB] for more information. The Chassis Reset 


command allows chassis logic (excluding the chassis device itself) to be reset. For host systems, this corresponds to 
a system hard reset. 


28.5 


Table 28-, Chassis Reset Command 
byte data field 


Request Data | - | 
Response Data Completion Code 


Chassis Identify Command 


This command causes the chassis to physically identify itself by a mechanism chosen by the system 
implementation; such as turning on blinking user-visible lights or emitting beeps via a speaker, LCD panel, etc. 
Unless the optional *Force Identify On” capability is supported and used, the Chassis Identify command 
automatically times out and deasserts the indication after a configurable time-out. Software must periodically 
resend the command to keep the identify condition asserted. This will restart the timeout. 


28.6 


Table 28-, Chassis Identify Command 
byte data field 


Request Data (1)! | [7:0] - Identify Interval in seconds. 1-based. Timing accuracy = -0/+20%. 
This field is optional. If this byte is not provided the default timeout 
shall be 15 seconds -0/+20%. Note that this byte can be overridden by 
optional byte 2. 

00h = Turn off Identify 
Force Identify On. This optional field enables software to command the 
Identify to be On indefinitely. The BMC implementation should return 
an error completion code if this byte is not supported. 
[7:1] - reserved 
[0]- 1b = Turn on Identify indefinitely. This overrides the values in byte 1. 
Ob = Identify state driven according to byte 1. 


Response Data Completion Code 


1. This parameter byte is optionally present. If not provided, the Chassis Identify can be used to turn 
on the Identify indication for the default timeout interval, but cannot be used to turn the indication 
off. 

2. This parameter byte is optionally present. If provided, it is highly recommended that the chassis 
provides a local manual mechanism that enables a user or service personnel to turn off Identify. If 
a local manual mechanism is not provided, AC removal (BMC reset) should remove the indication. 


Set Front Panel Enables 


The following command is used to enable or disable the buttons on the front panel of the chassis. (Button actually 
refers to the ability for the local user to be able to perform the specified functions via a pushbutton, switch, or 
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other ‘front panel’ control built into the system chassis.) These values will be returned in the Front Panel Button 
capabilities and disable/enable status (byte 5) of the Get Chassis Status command. 


Table 28-, Set Front Panel Button Enables Command 
byte data field 
Front Panel Button Enables 


[7:4] - reserved 

[3] - 1b = disable Standby (sleep) button for entering standby (sleep) 
(control can still be used to wake the system) 

[2] - 1b = disable Diagnostic Interrupt button 


[1] - 1b = disable Reset button 

[0] - 1b = disable Power off button for power off only (in the case there is a 
single combined power/standby (sleep) button, then this also 
disables sleep requests via that button) 


Response Data Completion Code 


28.7 Set Chassis Capabilities Command 


This command is used to set the values that will be returned for the Get Chassis Capabilities command into non- 
volatile storage associated with the Chassis Device. 


This command is recommended for all add-on bridge applications. 


Table 28-, Set Chassis Capabilities Command 
byte data field 
Request Data Capabilities Flags 
[7:2] - reserved 
[1]- 1b = Provides Front Panel Lockout (see 28.1, Get Chassis 
Capabilities) 
[0] - 1b = Provides intrusion 
Chassis FRU Info Device Address (see 28.1, Get Chassis Capabilities for a 
description of these addresses, their use, and the field formatting) 

Chassis SDR Device Address 
Chassis SEL Device Address 
Chassis SM Device Address 
Chassis Bridge Device Address 


Response Data Completion Code. Note, this command does not return an error completion 
code if an attempt is made to change a ‘read-only’ parameter. 
Software must check which fields in the response match the value 
from the request by using the Get Chassis Capabilities command. 
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28.8 Set Power Restore Policy Command 


This command can be used to configure the power restore policy. This configuration parameter is kept in non- 
volatile storage. The power restore policy determines how the system or chassis behaves when AC power returns 
after an AC power loss. The Get Chassis Status command returns the power restore policy setting. 


Table 28-, Set Power Restore Policy Command 
byte data field 
Request Data [7:3] - reserved 
[2:0] - power restore policy 
011b = no change (just get present policy support) 


010b = chassis always powers up after AC/mains is applied or 
returns 


001b = after AC/mains is applied or returns, power is restored to the 
state that was in effect when AC/mains was removed or lost 
000b = chassis always stays powered off after AC/mains is applied, 
power pushbutton or command required to power on system 


all other = reserved 
Response Data Completion Code. A non-zero completion code should be returned if an 
attempt is made to set a policy option that is not supported. 
power restore policy support (bitfield) 
[7:3] - reserved 
[2]- 1b = chassis supports always powering up after AC/mains returns 
[1]- 1b = chassis supports restoring power to state that was in effect when 
AC/mains was lost 
[0] - 1b = chassis supports staying powered off after AC/mains returns 
1. In some installations, the chassis’ main power feed may be DC based. For example, -48V. 
In this case, the power restore policy for AC/mains refers to the loss and restoration of the 
DC main power feed. 


28.9 Set Power Cycle Interval 


This command provides a mechanism for configuring the power cycle interval for the system. This interval 
determines the time that system power will be powered down during a power cycle operation initiated by the 
Chassis Control command or the watchdog time. The setting is non-volatile. 


Table 28-, Set Power Cycle Interval Command 
byte data field 


Request Data 1 [7:0] - Power Cycle Interval in seconds. 1-based. 
00h = no delay. 


Response Data Completion code. 


28.10 Remote Access Boot control 


The BMC allows a remote console application to optionally direct the boot process following a command to reset, 
power-up, or power-cycle the system. The remote console sets Boot Option flags prior to issuing a command to 
reset, power up, or power-cycle the system. The system BIOS can then read these flags after the system restarts 
and perform the requested boot operation. This will typically be used to direct the system to boot to an alternative 
partition or source in order to perform emergency remote recovery operations. 


The Boot Option parameter definitions follow the set of Boot Option parameters defined by the DMTF Pre-OS 
Working Group. 


Implementing Remote Access Boot control is optional. 
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28.11 Get System Restart Cause Command 


This command returns information about what action last caused the system to restart. BIOS can use this 
command in conjunction with the System Boot Options as additional information in determining whether to 
perform the requested boot operation. 


Table 28-, Get System Restart Cause Command 
byte data field 
Request Data 
Response Data Completion Code 


Restart Cause 
[7:4] - reserved 
[3:0] - Oh = unknown (system start/restart detected, but cause unknown) 
[required if this condition exists] 
1h = Chassis Control command [required] 
2h = reset via pushbutton [optional] 
3h = power-up via power pushbutton [optional] 
4h = Watchdog expiration (see watchdog flags) [required] 
5h = OEM [optional] 
6h = automatic power-up on AC being applied due to ‘always restore’ 
power restore policy (see 28.8, Set Power Restore Policy 
Command) [optional] 
7h = automatic power-up on AC being applied due to ‘restore previous 
power state’ power restore policy (see 28.8, Set Power Restore 
Policy Command) [optional] 
8h = reset via PEF [required if PEF reset supported] 
9h = power-cycle via PEF [required if PEF power-cycle supported] 
Ah = soft reset (e.g. CTRL-ALT-DEL) [optional] 
Bh = power-up via RTC (system real time clock) wakeup [optional] 
all other = reserved 


Channel number. (Channel that command was received over) 


28.12 Set System Boot Options Command 


392 


This command is used to set parameters that direct the system boot following a system power up or reset. The 
boot flags only apply for one system restart. It is the responsibility of the system BIOS to read these settings 
from the BMC and then clear the boot flags. 


It is possible that a remote console application could set the boot option flags and then be terminated either 
accidentally or intentionally. In this circumstance, it’s possible that a user initiated system restart could occur 
hours or even days later. If the boot options were used without examining the reset cause, this could cause an 
unexpected boot sequence. Thus, the BMC will automatically clear a ‘boot flags valid bit’ if a system restart is 
not initiated by a Chassis Control command within 60 seconds +/- 10% of the valid flag being set. The BMC 
will also clear the bit on any system resets or power-cycles that are not triggered by a System Control command. 
This default behavior can be temporarily overridden using the ‘BMC boot flag valid bit clearing’ parameter. 


Request Data 


Response Data 
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Table 28-, Set System Boot Options Command 
byte data field 


Parameter valid 
[7]- 1b = mark parameter invalid / locked 

Ob = mark parameter valid / unlocked 
[6:0] - boot option parameter selector 
Boot option parameter data, per Table 22-12, Boot Option Parameters. 
Passing 0-bytes of parameter data allows the parameter valid bit to be 
changed without affecting the present parameter setting. 


Completion Code. Generic plus the following command-specific completion 

codes: 

80h = parameter not supported. 

81h = attempt to set the ‘set in progress’ value (in parameter #0) when not in 
the ‘set complete’ state. (This completion code provides a way to 
recognize that another party has already ‘claimed’ the parameters) 

82h = attempt to write read-only parameter 


28.13 Get System Boot Options Command 


This command is used to retrieve the boot options set by the Set System Boot Options command. 


Request Data 


Response Data 


Table 28-, Get System Boot Options Command 
byte data field 


Parameter selector 
[7]- reserved 
[6:0] - boot option parameter selector 


[7:0] - Set Selector 

Selects a particular block or set of parameters under the given parameter 
selector. 

Write as 00h if parameter doesn’t use a Set Selector 


[7:0] - Block Selector 
Selects a particular block within a set of parameters. 
Write as 00h if parameter doesn't use a Block Selector. 


Note: As of this writing, there are no IPMI-specified Boot Options parameters 
that use the block selector. However, this field is provided for consistency with 
other configuration commands and as a placeholder for future extension of the 
IPMI specification. 


Completion Code. Generic plus the following command-specific completion 
codes: 


80h = parameter not supported. 


[7:4] - reserved 
[3:0] - parameter version. 1h for this specification unless otherwise specified. 


Parameter valid 

[7]- 1b = parameter marked invalid / locked 
Ob = parameter marked valid / unlocked 

[6:0] - boot option parameter selector 


Configuration parameter data, per Table 28-, Boot Option Parameters. 

If the rollback feature is implemented, the BMC makes a copy of the existing 
parameters when the ‘set in progress’ state becomes asserted (See the Set In 
Progress parameter #0). While the ‘set in progress’ state is active, the BMC 
will return data from this copy of the parameters, plus any uncommitted 
changes that were made to the data. Otherwise, the BMC returns parameter 
data from non-volatile storage. 
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Table 28-, Boot Option Parameters 


Parameter 


Set In Progress 
(volatile) 


service partition 
selector 
(semi-volatile) "1 


service partition scan 
(non-volatile) 


BMC boot flag valid bit 
clearing 
(semi-volatile) "1 
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Parameter Data (non-volatile unless otherwise noted) 


data 1 - This parameter is used to indicate when any of the following parameters are 
being updated, and when the updates are completed. The bit is primarily provided to alert 
software that some other software or utility is in the process of making changes to the 
data. 
An implementation can also elect to provide a ‘rollback’ feature that uses this information 
to decide whether to ‘roll back’ to the previous configuration information, or to accept the 
configuration change. 
If used, the roll back shall restore all parameters to their previous state. Otherwise, the 
change shall take effect when the write occurs. 
[7:2] - reserved 
[1:0] - 00b = set complete. If a system reset or transition to powered down state occurs 
while ‘set in progress’ is active, the BMC will go to the ‘set complete’ state. If 
rollback is implemented, going directly to ‘set complete’ without first doing a 
‘commit write’ will cause any pending write data to be discarded. 
01b = set in progress. This flag indicates that some utility or other software is 
presently doing writes to parameter data. It is a notification flag only, it is not 
a resource lock. The BMC does not provide any interlock mechanism that 
would prevent other software from writing parameter data while. 
10b = commit write (optional). This is only used if a rollback is implemented. The 
BMC will save the data that has been written since the last time the ‘set in 
progress’ and then go to the ‘set in progress’ state. An error completion 
code will be returned if this option is not supported. 
11b = reserved 
data 1 
[7:0] - service partition selector. This value is used to select which service partition BIOS 
should boot using. This document doesn’t specify which value corresponds to a 
particular service partition. 
00h = unspecified. 
data 1 
[7:2] - reserved 
[1]- 1b = Request BIOS to scan for specified service partition. BIOS clears this bit after 
the requested scan has been performed. 
[0] - 1b = Service Partition discovered. BIOS sets this bit to indicate it has discovered 
the specified service partition. The bit retains the value from the last scan. 
Therefore, to get up-to-date status of the discovery state, a scan may need to 
be requested. 
data 1- BMC boot flag valid bit clearing. Default = 00000b. 
[7:5] - reserved 
[4] - 1b = dont clear valid bit on reset/power cycle caused by PEF 
[3]- 1b = don’t automatically clear boot flag valid bit if Chassis Control command not 
received within 60-second timeout (countdown restarts when a Chassis 
Control command is received) 
[2]- 1b = don't clear valid bit on reset/power cycle caused by watchdog timeout 
[1]- 1b = don't clear valid bit on pushbutton reset / soft-reset (e.g. “Ctrl-Alt-Del”) 
[0] - 1b = don't clear valid bit on power up via power pushbutton or wake event 


boot info acknowledge 
(semi-volatile) "1 
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These flags are used to allow individual parties to track whether they've already seen and 
handled the boot information. Applications that deal with boot information should check 
the boot info and clear their corresponding bit after consuming the boot options data. 


data 1: Write Mask (‘write-only’. This field is returned as 00h when read. This is to 
eliminate the need for the BMC to provide storage for the Write Mask field.) 

[7]- 1b = enable write to bit 7 of Data field 

[6]- 1b = enable write to bit 6 of Data field 

[5] - 1b = enable write to bit 5 of Data field 

[4]- 1b = enable write to bit 4 of Data field 

[3] - 1b = enable write to bit 3 of Data field 

[2]- 1b = enable write to bit 2 of Data field 

[1]- 1b = enable write to bit 1 of Data field 

[0] - 1b = enable write to bit 0 of Data field 


data 2:Boot Initiator Acknowledge Data 

The boot initiator should typically write FFh to this parameter prior to initiating the boot. 
The boot initiator may write O's if it wants to intentionally direct a given party to ignore the 
boot info. This field is automatically initialized to OOh when the management controller is 
first powered up or reset. 

[7]- reserved. Write as 1b. Ignore on read. 

[6]- reserved. Write as 1b. Ignore on read. 

[5] - reserved. Write as 1b. Ignore on read. 

[4] - Ob = OEM has handled boot info. 

[3] - 0b = SMS has handled boot info. 

[2]- 0b =OS/service partition has handled boot info. 

[1]- Ob = OS Loader has handled boot info. 

[0] - Ob = BIOS/POST has handled boot info. 
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boot flags 
(semi-volatile) H] 
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data 1 
[7]- 1b = boot flags valid. The bit should be set to indicate that valid flag data is present. 
This bit may be automatically cleared based on the boot flag valid bit clearing 
parameter, above. 
[6] - Ob = options apply to next boot only. 
1b = options requested to be persistent for all future boots (i.e. requests BIOS to 
change its boot settings) 
Note: In order to set this bit remotely (over a session), the user must execute 
the Set System Boot Options command at ADMIN privilege level. In order to 
retain backward compatibility, this bit will be AUTOMATICALLY CLEARED 
by the BMC whenever the boot flags valid bit is clear (Ob). This is to avoid 
the possibility that this bit would already be set when an older application 
changes other options. Thus, this bit and the boot flags valid bit must be set 
simultaneously. 
[5] - BIOS boot type (for BIOS that support both legacy and EFI boots) 
Ob = “PC compatible” boot (legacy) 
1b = Extensible Firmware Interface Boot (EFI) 
[4:0] - reserved 


BIOS support for the following flags is optional. If a given flag is supported, it must cause 
the specified function to occur in order for the implementation to be considered to be 
conformant with this specification. 


The following parameters represent temporary overrides of the BIOS default settings 
when data1[6] has value Ob (one-boot), and represent requests to persistently change the 
BIOS boot behavior when data1[6] has value 1b (persistent). BIOS should only use the 
following flags when the boot flags valid bit (data1[7]) is set (1b). 


If data[6] = Ob (one-boot) a value of 0 for a given data2 parameter indicates that BIOS 
should use its default configuration for the given option (no override) - a non-zero value 
requests BIOS to enter the requested state. 


If data[6] = 1b (persistent) BIOS is requested to change its setting according to the flag. 
This only applies to parameters labeled “©”. Settings for other parameters are ignored. 


data 2 
[7]- 1b= CMOS clear 
[6]- 1b= Lock Keyboard 
[5:2] - Boot device selector © 
0000b = No override 
0001b = Force PXE 
0010b = Force boot from default Hard-drivel?! 
0011b = Force boot from default Hard-drive, request Safe Model?! 
0100b = Force boot from default Diagnostic Partitionl2] 


0101b = Force boot from default CD/DVDI?I 

0110b = Force boot into BIOS Setup 

0111b = Force boot from remotely connected (redirected) Floppy/primary 
removable media[2] 

1001b = Force boot from primary remote medial?! 


1000b = Force boot from remotely connected (redirected) CD/DVD! 
1010b = reserved 


1011b = Force boot from remotely connected (redirected) Hard Drivel?! 
1100-1110b = Reserved 


1111b = Force boot from Floppy/primary removable medial! 
[1]- 1b = Screen Blank 
[0] - 1b = Lock out Reset buttons © 


data 3 

[7]- 1b= Lock out (power off/ sleep request) via Power Button © 

[6:5] - Firmware (BIOS) Verbosity (Directs what appears on POST display) © 
00b = system default 
01b = request quiet display 
10b = request verbose display 
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11b = reserved 

[4] - Ob (1b = Force progress event traps for [IPMI 2.0]) ©. 

[3]- 1b = User password bypass ©. When set to 1b, the managed clients BIOS boots 
the system and bypasses any user or boot password that might be set in the 
system. This option allows a system administrator to, for example, force a 
system boot via PXE in an unattended manner. 

[2]- 1b = Lock Out Sleep Button ©. When set to 1b, directs BIOS to disable the sleep 
button operation for the system, normally until the next boot cycle. Client 
instrumentation might provide the capability to re-enable the button 
functionality without rebooting. (This only applies to systems that have a 
separate sleep button on the chassis.) 

[1:0] - Console Redirection control © 

00b = console redirection occurs per BIOS configuration setting (system default) 
01b = suppress (skip) console redirection if enabled 
10b = request console redirection be enabled 
11b = reserved 
data 4 
[7:4] - reserved 


[3] - BIOS Shared Mode Override!’ 
Can be used to request BIOS to temporarily place the channel into Shared access mode. 
Per the recommendations in Table 14-, Serial Port Sharing Access Characteristics, 
‘Shared’ access causes the baseboard serial controller to remain enabled after 
POST/start of OS boot while also allowing the BMC to be accessible. This can be useful 
when booting to an alternative device such as a Diagnostic Partition since it means the 
partition can use the serial port but that communication with the BMC can remain 
available if the partition software fails. 
Note: BIOS should only pay attention this field if when the ‘valid’ flag is set and the 
‘BIOS/POST has handled boot info’ flag is set. 
1b = Request BIOS to temporarily set the access mode for the channel specified in 
parameter #6 to ‘Shared’. This is typically accomplished by sending a ‘Set 
Channel Access’ command to set the volatile access mode setting in the 
BMC. 
Ob = No request to BIOS to change present access mode setting. 


[2:0] - BIOS Mux Control Override 
Can be used to request BIOS to force a particular setting of the serial/modem mux at the 
conclusion of POST / start of OS boot. This override takes precedence over the mux 
settings for the access mode even if the BIOS Shared Mode Override is set. 
Note: BIOS should only pay attention this field if when the ‘valid’ flag is set and 
BIOS/POST has handled boot info flag is set. 
000b = BIOS uses recommended setting of the mux at the end of POST (See 
Table 14-, Serial Port Sharing Access Characteristics for more info.) 
001b = Requests BIOS to force mux to BMC at conclusion of POST/start of OS- 
boot. If honored, this will override the recommended setting of the mux at 
the end of POST (See Table 14-, Serial Port Sharing Access 
Characteristics for more info.) 
010b = Requests BIOS to force mux to system at conclusion of POST/start of OS- 
boot. If honored, this will override the recommended setting of the mux at 
the end of POST (See Table 14-, Serial Port Sharing Access 
Characteristics for more info.) 


[7:5] -— reserved 
[4:0] - Device Instance Selector 
If this value is 0, then there is no change to Boot Device Selector behavior. If this 
value is not zero, then the behavior of Boot Device Selector for the following 
values 
0001b = Force PXE 
0010b = Force boot from default Hard-drive, 
0011b = Force boot from default Hard-drive, request Safe Mode, 
0101b = Force boot from default CD/DVD, 
0111b = Force boot from remotely connected (redirected) Floppy/primary 
removable media 
1000b = Force boot from remotely connected (redirected) CD/DVD 
1001b = Force boot from primary remote media 
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boot initiator info 
(semi-volatile) "1 


boot initiator mailbox 
(semi-volatile) 21 


OEM Parameters 
(optional. Non-volatile 
or volatile as specified 
by OEM) 
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96:127 


1011b = Force boot from remotely connected (redirected) Hard Drive 
1111b = Force boot from Floppy/primary removable media 
is modified to use the value in this parameter to select a particular instance of a 
device of that type to boot from. 


For example, if the Boot Device Selector were 0010b (Hard-drive) and the Logical 
Device selector was 00010b, it would select logical external hard drive 1. Devices 
instances may be physical or logical depending on the system. 


The system should attempt to boot from the specified device instance first. If the 
boot fails the system should attempt booting using the system's boot order 
configuration. If the requested value is out of the range of logical devices, then the 
system should treat the value as zero. 


00000b = no specific device instance requested 
00001b to 01111b = external (direct attached) device instance 1 to 15, 
respectively 

10000b = reserved 

10001b to 11111b = internal device instance number 1 to 15, respectively 
Address & Identity information for the party that initiated the boot. The party that initiates 
the boot writes this parameter and the boot info acknowledge parameter prior to issuing 
the command that causes the system power up, power cycle, or reset. This data is 
normally written by the remote console application, not the BMC. 


boot source 

data 1- Channel Number. Channel that will deliver the boot command (e.g. chassis 
control). BIOS and boot software (e.g. service partition or OS loader) can use the 
Get Session Info command to find out information about the party that initiated the 
boot. 

[7:4] - reserved 

[3:0] - Channel Number 


data 2:5 - Session ID. Session ID for session that the boot command will be issued over. 
This value can be used with the Get Session Info command to find out information 
about the party that initiated the boot. For IPMI v2.0/RMCP+ this is the Managed 
System Session ID that was generated by the BMC when the session was 
activated. 


data 6:9 - Boot Info Timestamp. This timestamp is used to help software determine 
whether the boot information is ‘stale’ or not. A service partition or OS loader may 
elect to ignore the boot information if it is older than expected. 
The boot initiator should load this field with the timestamp value from the Get SEL 
Time command prior to issuing the command that initiates the boot. 
This parameter is used as a ‘mailbox’ for holding information that directs the operation of 
the OS loader or service partition software. The data content is specified by the software 
vendor. 


Note: Since this information will be retained by the BMC and may be readable by other 
software entities, care should be taken to avoid using it to carry ‘secret’ data. 


data1: Set Selector = block selector 
Selects which 16-byte info block to access. 0-based. 


data 2:(17) block data 

The first three bytes of block #0 are required to be an IANA Enterprise ID Number (least 
significant byte first) for the company or organization that has specified the loader. 

Up to 16-bytes per block of information regarding boot initiator, based on protocol and 
medium. 

An implementation is required to support at least 80-bytes (five blocks) of storage for this 
command. Previous values are overwritten. The BMC does not automatically clear any 
remaining data bytes if fewer than 16 bytes are written to a given block. 

This range is available for special OEM configuration parameters. The OEM is identified 
according to the Manufacturer ID field returned by the Get Device ID command. 
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1. The designation ‘semi-volatile’ means that the parameter will be kept across system power cycles, resets, system power 
on/off, and sleep state changes, but will not be preserved if the management controller loses standby power or is cold reset. 
Parameters designated as ‘semi-volatile’ are initialized to O's upon controller power up or hard reset, unless otherwise 
specified. 

2. IPMI allows software to use the boot initiator mailbox as a way for a remote application to pass OEM parameters for 
additional selection of the boot process and direction of the startup of post-boot software. If additional parameters are not 
included, the system boots the primary/first-scanned device of the type specified. 

3. When BIOS temporarily changes the access mode to ‘Shared’, the BMC should operate according to the description for that 
mode provided in Table 14-, Serial Port Sharing Access Characteristics. Because this is a volatile setting, the BMC will return 
to operating according to the non-volatile setting on the next system power down or hard reset. A remote application that 
uses this bit should be aware of possible differences in operation between the non-volatile setting and Shared mode. For 
example, the differences in answering behavior between “Shared” mode and “Always Available” mode. 

4. BIOS should set this access mode and, if serial port sharing is enabled, configure the system UART according to Table 14-, 
Serial Port Sharing Access Characteristics prior to launching the load (boot) of the operating system. lt is recommended that 
this operation be performed as early in POST as feasible. In any case, a remote application should be aware that the BIOS 
may be operating according to the non-volatile setting during a significant portion of POST until it reaches the point where it 
acts on the BOOT options. 


28.14 Get POH Counter Command 


This version of IPMI provides a specification for an optional, POH (Power-On Hours) counter. The management 
controller automatically increments non-volatile storage at the specified rate whenever the system is powered up. 
It is recommended that this command be implemented in the BMC to provide a standardized location for this 


function. 


Note that in a power-managed system, the definition of “powered up’ can be somewhat ambiguous. The definition 
used here is that the power-on hours shall accumulate whenever the system is in the operational (SO) state. An 
implementation may elect to increment power-on hours in the $1 and S2 states as well. 


‘Clear’ or ‘Set’ commands are not specified for this counter. This is because the counter is most typically used for 
warranty tracking or replacement purposes where changing or clearing the counter would defeat the purpose. 


The following command is used for accessing the POH Counter. This command returns the present reading of the 
counter, plus the number of counts per hour. 


Table 28-, Get POH Counter Command 
byte data field 


Request Data | - | 
Response Data Completion Code 


Minutes per count. 
Counter reading. LS Byte first. 


When the system is powered down between counts, the counter either picks up incrementing at the offset at which 
the power down occurred, or starts counting at 0 minutes from the last counter reading, depending on the choice 
of the implementer. In any case, the time does not get ‘rounded up” to the next count as a result of powering down 
between counts. 
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29. Event Commands 


The ‘Sensor/Event’ Network Function is used for device functionality related to the transmission, reception, and 
handling of ‘Event Messages’ and platform sensors. 


What is commonly referred to as an ‘Event Message’ is actually a Sensor/Event Message with a command byte of 
‘02h’. The request is also referred to as an ‘Event Request Message’, while the corresponding response is referred to 
as an ‘Event Response Message’. 


The following presents the list of the Event commands under the ‘Sensor/Event’ Network Function. Refer to 
Appendix G - Command Assignments for the specification of the Network Function and Command (CMD) values 
and privilege levels for these commands. 


Table 29-, Event Commands 


Mandatory/Optional 
Section Event Event 
Command Defined | Generator | Receiver 


Set Event Receiver 
Get Event Receiver 
Platform Event (a.k.a. “Event Message”) 


29.1 Set Event Receiver Command 


This global command tells a controller where to send Event Messages. The slave address and LUN of the Event 
Receiver must be provided. A value FFh for the Event Receiver Slave Address disables Event Message generation 
entirely. This command is only applicable to management controllers that act as IPMB Event Generators. 


A device that receives a ‘Set Event Receiver’ command shall ‘re-arm’ event generation for all its internal sensors. 
This means internally re-scanning for the event condition, and updating the event status based on the result. This 
will cause devices that have any pre-existing event conditions to transmit new event messages for those events. 


=> A reading/state unavailable (formerly “initial update in progress”) bit is provided with the 
Get Sensor Reading and Get Sensor Event Status commands to help software avoid getting 
incorrect event status due to a re-arm. For example, suppose a controller only scans for an 
event condition once every four seconds. Software that accessed the event status using the Get 
Sensor Reading command could see the wrong status for up to four seconds before the event 
status would be correctly updated. A controller that has slow updates must implement the 
reading/state unavailable bit, and should not generate event messages until the update has 
completed. Software should ignore the Event Status bits while the reading/state unavailable 


bit is set. 
Table 29-, Set Event Receiver 
byte data field 
Request Data Event Receiver Slave Address. OFFh disables Event Message Generation, 


Otherwise: 
[7:1] - IPMB (ICH Slave Address 
[0] - always Ob when [7:1] hold DC slave address 


2 | [7:2] - reserved 
[1:0] - Event Receiver LUN 


Response Data Completion Code 
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29.2 Get Event Receiver Command 


This global command is used to retrieve the present setting for the Event Receiver Slave Address and LUN. This 
command is only applicable to management controllers that act as IPMB Event Generators. 


Table 29-, Get Event Receiver Command 
byte data field 


Request Data LUD] 
Response Data = Completion Code. 


Event Receiver Slave Address. OFFh indicates Event Message Generation 
has been disabled. Otherwise: 


# 1] IPMB (I?C) Slave Address 
always Ob when [7:1] hold DC slave address 


a [7:2] - reserved 
[1:0] - Event Receiver LUN 


29.3 Platform Event Message Command 


This command may be thought of as a request for the BMC to process the event data that the command contains. 
Typically, the data will be logged to the System Event Log (SEL). Depending on the implementation, the data 
may also go to the Event Message Buffer and processed by Platform Event Filtering (PEF). 


Table 29-, Platform Event (Event Message) Command 


IPMB MESSAGING SYSTEM INTERFACE 
(IPMB, LAN, Serial/Modem, PCI Mgmt. Bus) 


byte data field byte data field 
[= [Generator ID (RaSA, RaLUN) 


Request Data SE 


Sensor Type Sensor Type 


Ce [Even Data fs [event CS 

Event Data? 

[7 [Even Data f e Event Data — O 

Response Data 


The Generator ID field is a required element of an Event Request Message. For IPMB messages, this field is 
equated to the Requester’s Slave Address and LUN fields. Thus, the Generator ID information is not carried in the 
data field of an IPMB request message. 


For ‘system side’ interfaces, it is not as useful or appropriate to ‘overlay’ the Generator ID field with the message 
source address information, and so it is specified as being carried in the data field of the request. 


29.4 Event Request Message Fields 


An Event Request Message contains the following fields for the Event Receiver, regardless of whether the 
message is received from the IPMB or from a ‘system side’ messaging interface, such as the KCS interface. Most 
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of the information is passed in the data field of the message, however, in some cases field information is extracted 
from the ‘message header’. 


Table 29-, Event Request Message Fields 


Field Description 

Generator ID | This field identifies the device that has generated the Event Message. This is the 7-bit Requester's 
Slave Address (RqSA) and 2-bit Requester’s LUN (RqLUN) if the message was received from the 
IPMB, or the 7-bit System Software ID if the message was received from system software. 


EvMRev One byte. Event Message Revision. This field is used to identify different revisions of the Event 
Message format. The revision number shall be 04h for Event Messages that comply with the format 
given in this specification. IPMI v1.0 messages use O3h. It is recommended that software be able to 
interpret both versions. 


Sensor Type One byte. Indicates the event class or type of sensor that generated the Event Message. The 
Sensor Type Codes are specified in Table 42-, Sensor Type Codes. 


Sensor # One byte. A unique number (within a given sensor device) representing the ‘sensor’ within the 
management controller that generated the Event Message. Sensor numbers are used for both 
identification and access of sensor information, such as getting and setting sensor thresholds. 


Event Dir 1-bit. Indicates the event transition direction. (0 = Assertion Event, 1 = Deassertion Event) 


Event Type 7-bits. This field indicates the type of threshold crossing or state transition (trigger) that produced the 
event. This is encoded using the Event/Reading Type Code. See Section 42, Sensor and Event 
Code Tables. 


Event Data One to three Bytes. The remainder of the Event Message data according to the class of the Event 
Type for the sensor (threshold, discrete, or OEM). The contents and format of this field is specified 
in Table 29-, Event Request Message Event Data Field Contents, below. 


The following illustrates which fields from the Event Request Message get transferred to the System Event 
Record. 


29.5 IPMB Event Message Formats 


The following figure illustrates the formatting of an Event Request Message as an ‘IPMB’ message on an I°C bus, 
per the Intelligent Platform Management Bus Communications Protocol v1.0. 


Figure 29-, IPMB Event Request Message Format 


| RSSA _|NetFn [/RsLUN | Chk1 
/RGLUN** 
Cmd=02 | EvMRev | Sensor Type |Sensor # | Event Dir | Event Type | Event Data | Chk2 


** These fields constitute the Generator ID’ field for the Event Request Message. 
[ ] Shading designates fields that are not stored in the event record. 


The Event Receiver device responds to IPMB Event Request Messages by simply issuing the Event Response 
Message with a single ‘Completion Code’ byte in the data field and a command code of 02h in IPMB Response 
Message format. 


29.6 System Interface Event Request Message Format 


Event Request Messages are formatted differently over the System Interface than they are over the IPMB or 
interfaces that use the IPMB message format. The following figure illustrates the formatting of an Event Request 
Message as it would be transmitted over the SMIC interface. This is provided for illustration purposes only. Refer 
to the individual sections for the System Interfaces for more information: Section Section 9.4, Logging Events 
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from System Software via KCS Interface, 10.16, Logging Events from System Software via SMIC, and Section 
11.5, Logging Events from System Software via BT Interface. SSIF uses the same format as KCS. 


Figure 29-, Example SMIC Event Request Message Format 


Cmd=02 | 7-bit Software ID** 
Sensor Type Event Dir | Event Type | Event Data 


kk 


This field constitutes the ‘Generator ID’ field for the Event Request Message. 
si Shading designates fields that are not stored in the event record. 
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29.7 Event Data Field Formats 


The contents of the Event Data field in an Event Request Message (Event Message) is dependent on the sensor 
class of the sensor. The sensor class obtained from the Event/Reading Type Code specifies whether the sensor 
event is threshold based, discrete, or OEM defined. Each Event Type is associated with a sensor class. An 
application can extract the sensor class, and determine the corresponding Event Data format, from the 
Event/Reading Type Code that was received in the Event Type field in the Event Message. See section 42.1, 
Event/Reading Type Codes, for more information. 


Table 29-, Event Request Message Event Data Field Contents 


Sensor 
Class Event Data 


| threshold. |EvetDaa 
[7:6] - 
[3:0] - 
Event Data 2 reading that triggered event, FFh or not present if unspecified. 
Event Data 3 threshold value that triggered event, FFh or not present if unspecified. If present, byte 2 must be 
present. 


00b = unspecified byte 2 

01b = trigger reading in byte 2 

10b = OEM code in byte 2 

11b = sensor-specific event extension code in byte 2 
00b = unspecified byte 3 

01b = trigger threshold value in byte 3 

10b = OEM code in byte 3 

11b = sensor-specific event extension code in byte 3 


Offset from Event/Reading Code for threshold event. 


00b = unspecified byte 2 

01b = previous state and/or severity in byte 2 

10b = OEM code in byte 2 

11b = sensor-specific event extension code in byte 2 
00b = unspecified byte 3 

01b = reserved 

10b = OEM code in byte 3 

11b = sensor-specific event extension code in byte 3 


Offset from Event/Reading Code for discrete event state 


Event Data 3 is also not present 
Optional offset from ‘Severity’ Event/Reading Code. (OFh if unspecified) 
Optional offset from Event/Reading Type Code for previous discrete event state. (OFh if unspecified.) 


discrete Event Data 1 
[7:6] - = ifi 
[3:0] - i i 
Event Data 2 Optional OEM code or severity / previous state fields. May be not present if byte is unspecified AND 
[7:4] - F Se o 9 ified). 
[3:0] - i i i i É i ified. 
Event Data 3 Optional OEM code. FFh or not present if unspecified. 


00b = unspecified byte 2 

01b = previous state and/or severity in byte 2 
10b = OEM code in byte 2 

11b = reserved 

00b = unspecified byte 3 

01b = reserved 

10b = OEM code in byte 3 

11b = reserved 

Offset from Event/Reading Type Code 


Event Data 3 is also not present 
Optional OEM code bits or offset from ‘Severity’ Event/Reading Type Code. (OFh if unspecified) 
Optional OEM code or offset from Event/Reading Type Code for previous event state. (OFh if unspecified) 


OEM Event Data 1 
[7:6] - = ifi 
[3:0] - i 
Event Data 2 Optional OEM code or severity / previous state fields. May be not present if byte is unspecified AND 
[7:4] - i i ity’ i 3 i ified). 
[3:0] - i i i V i ified). 
Event Data 3 Optional OEM code. FFh or not present if unspecified. 


O/M = Optional/Mandatory. Mandatory indicates that the byte must be present in all messages. Optional bytes may be left 
out of messages, as specified. If an optional byte is not present, the Event Receiver shall substitute the value FFh in the 
corresponding Event Data byte position when transferring the information to the System Event Log function. 
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30. PEF and Alerting Commands 


This section describes the formats of the commands related to configuring and controlling the Platform Event 
Filtering (PEF) and Alerting capabilities. None of the commands in the following table are required unless PEF or 
Alerting is supported. Refer to Appendix G - Command Assignments for the specification of the Network Function 
and Command (CMD) values and privilege levels for these commands. 


Table 30-, PEF and Alerting Commands 


Section 
Command Defined 


Get PEF Capabilities 30.1 
Arm PEF Postpone Timer 30.2 
Set PEF Configuration Parameters 30.3 


Get PEF Configuration Parameters 30.4 
Set Last Processed Event ID 30.5 


Get Last Processed Event ID 30.6 
Alert Immediate 30.7 
PET Acknowledge 30.8 


1. Mandatory if PEF or Alerting is supported 
2. Mandatory if Alerting is supported 
3. Mandatory if LAN or PPP Alerting is supported 


oo <s|<s<s<s|<s<s 


30.1 Get PEF Capabilities Command 


This command returns the information about the implementation of PEF on the BMC. 


Table 30-2, Get PEF Capabilities Command 

3 [7]- 1b = OEM Event Record Filtering supported 
[6]- reserved 

Action Support 

[5] - 1b = diagnostic interrupt 

[4]- 1b = OEM action 

[3] - 1b = power cycle 

[2]- 1b = reset 

[1]- 1b = power down 

[0]- 1b= Alert 
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Table 30-, Get PEF Capabilities Command 
byte data field 
Request Data 


Response Data Completion Code 


PEF Version (BCD encoded, LSN first, 51h for this specification. 51h > 
version 1.5) 

[7]- 1b = OEM Event Record Filtering supported 

[6]- reserved 

Action Support 


[5] - 1b = diagnostic interrupt 

[4]- 1b= OEM action 

[3]- 1b = power cycle 

[2]- 1b = reset 

[1]- 1b = power down 

[0]- 1b= Alert 

Number of event filter table entries (1 based) 


30.2 Arm PEF Postpone Timer Command 


This command is used by software to enable and arm the PEF Postpone Timer. The command can also be used by 
software to disable PEF indefinitely during run-time. Once enabled, the timer automatically starts counting down 
whenever the last software-processed event Record ID is for a record that is not equal to the most recent (last) 


SEL record. The countdown will begin immediately if the Record IDs are already different when the timer is 
armed. 


In order to keep the PEF Postpone Timer from expiring, software must use the Set Last Processed Event ID 
command to update the last software-processed Record ID to match the value for the last SEL record. This will 


cause the BMC to stop the timer and rearm it to start counting down from the value that was passed in the Arm 
PEF Postpone Timer command. 


The Get Last Processed Event ID command can be used to retrieve the present value for the last SEL record’s 
Record ID, the last BMC-processed Record ID, and the last software-processed Record ID. 


Table 30-, Arm PEF Postpone Timer Command 
byte data field 


Request Data [7:0] - PEF Postpone Timeout, in seconds. 01h > 1 second. 
00h = disable Postpone Timer (PEF will immediately handle events, if 
enabled). The BMC automatically disables the timer whenever the 
system enters a sleep state, is powered down, or reset. 
Oth - FDh = arm timer. Timer will automatically start counting down from given 
value when the last-processed event Record ID is not equal to the last 
received event’s Record ID. 


FEh = Temporary PEF disable. The PEF Postpone timer does not countdown 


from the value. The BMC automatically re-enables PEF (if enabled in 
the PEF configuration parameters) and sets the PEF Postpone timeout 
to 00h whenever the system enters a sleep state, is powered down, or 
reset. Software can cancel this disable by setting this parameter to OOh 
or O1h-FDh. 


FFh = get present countdown value 


Response Data 1 Completion Code 
2 Present timer countdown value 


30.3 Set PEF Configuration Parameters Command 


This command is used for setting parameters such as PEF enable/disable and for entering the configuration of the 
Event Filter table and the Alert Strings. 
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Table 30-, Set PEF Configuration Parameters Command 
byte data field 


Request Data 


Response Data 


Parameter selector 
[7]- reserved 
[6:0] - Parameter selector 


Configuration parameter data, per Table 24-6, PEF Configuration Parameters. 


Completion Code. Generic plus the following command-specific completion 
codes: 


80h = parameter not supported. 

81h = attempt to set the ‘set in progress’ value (in parameter #0) when not in 
the ‘set complete’ state. (This completion code provides a way to 
recognize that another party has already ‘claimed’ the parameters) 

82h = attempt to write read-only parameter 

83h = attempt to read write-only parameter 


30.4 Get PEF Configuration Parameters Command 


This command is used for retrieving the configuration parameters from the Set PEF Configuration command. 


Table 30-, Get PEF Configuration Parameters Command 


Request Data 


Response Data 


byte 


data field 

[7] - 1b = get parameter revision only. 
Ob = get parameter 

[6:0] - Parameter selector 


Set Selector (00h if parameter does not require a Set Selector) 


Block Selector (00h if parameter does not require a block number) 


Completion Code. Generic plus the following command-specific completion 
codes: 
80h = parameter not supported. 
[7:0] - Parameter revision. 
Format: MSN = present revision. LSN = oldest revision parameter is 
backward compatible with. 11h for parameters in this specification. 
The following data bytes are not returned when the ‘get parameter revision 
only’ bit is 1b. 


Configuration parameter data, per Table 24-6, PEF Configuration Parameters. 
If the rollback feature is implemented, the BMC makes a copy of the existing 
parameters when the ‘set in progress’ state becomes asserted (See the Set In 
Progress parameter #0). While the ‘set in progress’ state is active, the BMC 
will return data from this copy of the parameters, plus any uncommitted 
changes that were made to the data. Otherwise, the BMC returns parameter 
data from non-volatile storage. 
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Table 30-, PEF Configuration Parameters 


Parameter # Parameter Data 
Set In Progress 0 data 1 - This parameter is used to indicate when any of the following 
(volatile) parameters are being updated, and when the updates are completed. 

The bit is primarily provided to alert software than some other software or 

utility is in the process of making changes to the data. 

An implementation can also elect to provide a ‘rollback’ feature that uses 

this information to decide whether to ‘roll back’ to the previous 

configuration information, or to accept the configuration change. 

If used, the roll back shall restore all parameters to their previous state. 

Otherwise, the change shall take effect when the write occurs. 

[7:2] - reserved 

[1:0] - 00b = set complete. If a system reset or transition to powered 

down state occurs while ‘set in progress’ is active, the 
BMC will go to the ‘set complete’ state. If rollback is 
implemented, going directly to ‘set complete’ without first 
doing a ‘commit write’ will cause any pending write data to 
be discarded. 

01b = set in progress. This flag indicates that some utility or other 
software is presently doing writes to parameter data. lt is a 
notification flag only, it is not a resource lock. The BMC 
does not provide any interlock mechanism that would 
prevent other software from writing parameter data while. 

10b = commit write (optional). This is only used if a rollback is 
implemented. The BMC will save the data that has been 
written since the last time the ‘set in progress’ and then go 
to the ‘set in progress’ state. An error completion code will 
be returned if this option is not supported. 

11b = reserved 

PEF control 1 data 1 
(non-volatile) [7:4]- reserved 
[3]- PEF Alert Startup Delay disable. (optional) 

1b = enable PEF Alert Startup delay 

Ob = disable PEF startup delay. 

[2]- PEF Startup Delay disable. (optional) 

An implementation that supports this bit should also provide 
a mechanism that allows the user to Disable PEF in case 
the filter entries are programmed to cause an ‘infinite loop’ 
of PEF actions (such as system resets or power cycles) 
when the PEF startup delay is disabled. If this bit is not 
implemented the PEF startup delay must always be 
enabled. 

1b = enable PEF startup delay on manual (pushbutton) system 
power-ups (from S4/S5) and system resets (including 
system resets initiated by PEF). 

Ob = disable PEF startup delay. 

[1]- 1b = enable event messages for PEF actions. If this bit is set, 
each action triggered by a filter will generate an event 
message for the action. These allow the occurrence of PEF- 
triggered actions to be logged (if event logging is enabled). 
The events are logged as System Event Sensor 12h, offset 
04h. See Table 42-, Sensor Type Codes.) These event 
messages are also subject to PEF. 

Ob = disable event messages for PEF actions. 

[0] - 1b = enable PEF. 

Ob = disable PEF. 
PEF Action global control 2 data 1 
(non-volatile) [7:6] - reserved 

[5]- 1b = enable diagnostic interrupt 

[4]- 1b = enable OEM action 

[3]- 1b = enable power cycle action (No effect if power is already off) 

[2]- 1b = enable reset action 

[1]- 1b = enable power down action 

[0] - 1b= enable Alert action 


Intelligent Platform Management Interface Specification 


Parameter # Parameter Data 
PEF Startup Delay 3 data 1 - time to delay PEF after a system power-ups (from S4/S5) and 
å J ; resets. Default = 60 seconds. If this parameter is not provided, the 
(optional, non-volatile) default PEF Startup Delay must be implemented. Enable/disable of the 
delay is configured using the PEF Control parameter, above. If this 
parameter is supported, a 00h value can also be used to disable the 
delay if necessary. See Section 17.4, PEF Startup Delay, for more 
information. 
Note: An implementation that supports this parameter should also 
provide a mechanism that allows the user to Disable PEF in case the 
filter entries are programmed to cause an ‘infinite loop’ of PEF actions 
under the situation where this parameter is set to too short an interval to 
allow a user to locally disable PEF. An implementation is allowed to force 
this parameter to a minimum, non-zero value. 
PEF Startup Delay 
[7:0] - PEF Startup Delay in seconds, +/- 10%. 1-based. 00h = no delay. 
PEF Alert Startup Delay 4 data 1 - time to delay Alerts after system power-ups (from S4/S5) and 
(optional, non-volatile) resets. Default = platform-specific. 60-seconds typical, though may be 
longer on systems that require more startup time before user can take 
action to disable PEF. If this parameter is not provided, a default PEF 
Startup Delay, appropriate for the platform, must be implemented. 
Enable/disable of the delay can also be optionally configured using the 
PEF Control parameter, above. An implementation can separately 
implement this parameter and/or the enable/disable bit. 
PEF Alert Delay 
[7:0] - PEF Alert Startup Delay in seconds, +/- 10%. 1-based. 
00h = no delay. 
Number of Event Filters 5 Number of event filters supported. 1-based. This parameter does not 
(READ ONLY) need to be supported if Alerting is not supported. 
[7:0] - number of event filter entries. 0 = alerting not supported. 
Event Filter Table, (non- 6 data 1 - Set Selector = filter number. 
volatile) [7:0] - Filter number. 1-based. 00h = reserved. 
data 2:21 - filter data 
Event Filter Table Data 1 7 This parameter provides an aliased access to the first byte of the event 
(non-volatile) filter data. This is provided to simplify the act of enabling and disabling 
individual filters by avoiding the need to do a read-modify-write of the 
entire filter data. 
data 1 - Set Selector = filter number 
[7:0] - Filter number. 1-based. 00h = reserved. 
data 2 - data byte 1 of event filter data 
Number of Alert Policy 8 Number of alert policy entries supported. 1-based. This parameter does 
Entries not need to be supported if Alerting is not supported. 
(READ ONLY) [7]- reserved 
[6:0] - number of alert policy entries. 0 = alerting not supported. 
Alert Policy Table 9 data 1 - Set Selector = entry number 
(non-volatile) [7]- reserved 
[6:0] - alert policy entry number. 1-based. 
data 2:4 - entry data 
System GUID 10 data 1 Used to fill in the GUID field in a PET Trap. Stored per Table 20-, 
(non-volatile) GUID Format. 
[7:1] -reserved 
[0] -1b = BMC uses following value in PET Trap. 
Ob = BMC ignores following value and uses value returned from 
Get System GUID command instead. 
2:17 - System GUID 
Number of Alert Strings 11 Number of alert strings supported in addition to Alert String 0. 1-based. 


(READ ONLY) 


This parameter does not need to be supported if Alerting is not 
supported. 

[7] - reserved 

[6:0] - number of alert strings. 
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Parameter 


Parameter Data 


Alert String Keys 
(volatile) & (non-volatile) - 
see description 


Sets the keys used to look up Alert String data in PEF. This parameter 
does not need to be supported if Alerting is not supported. 
data 1 - Set Selector = Alert string selector. 
[7]- reserved. 
[6:0] - string selector. 
0 = selects volatile string parameters 
01h-7Fh = non-volatile string selectors 


PEF uses the following Event Filter Number and the Alert String Key 
fields to look up the string associated with a particular event. String 0 is a 
special, volatile string reserved for use by the Alert Immediate command. 


The following two fields are used by PEF to look up a particular Alert 
String based on information obtained from the alert policy entry. The 
fields should typically be set to 0’s (unspecified) for string selector 0. PEF 
will scan the values for string 0 when doing a look up, so the string 0 
values can be set to non-zero values for PEF testing/debug purposes in 
order to avoid writes to non-volatile storage. 


data 2 - Event Filter Number 
[7]- reserved. 
[6:0] - Filter number. 1-based. 00h = unspecified. 


data 3 - Alert String Set 
[7]- reserved 
[6:0] - Set number for string. 1-based. 00h = unspecified. 


Alert Strings 
(volatile) & 
(non-volatile) - see 
description. 


13 


Sets the Alert String data. The string data that should be used is 
dependent on the Channel and Alert Type. This parameter does not 
need to be supported if Alerting is not supported. 


For Dial paging, the BMC automatically follows the string with a <CR> 
(carriage return) character when sending it to the modem. 


For TAP paging the string corresponds to ‘Field 2’, the Pager Message. 
Note that while the string accepts 8-bit ASCII data, the TAP 
implementation only supports 7-bit ASCII. 

The BMC shall automatically zero the 8" bit when transmitting the string 
during TAP paging. 


String 0 is a special, volatile string reserved for use by the Alert 
Immediate command. 
data 1 - Set Selector = string selector. 
[7] - reserved. 
[6:0] - string selector. 
0 = selects volatile string 
01h-7Fh = non-volatile string selectors 
data 2 - Block Selector = string block number to set, 1 based. Blocks 
are 16 bytes. 


data 3:N- String data. Null terminated 8-bit ASCII string. 16-bytes max. 
per block. 


Number of Group Control 
Table entries 
(READ ONLY) 


(optional. Present if BMC 
supports automatic ICMB 
Group Power Control. 
See ICMB specification 
for details.) 
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data 1 - Number of group control table entries. 1-based (4 min, 8 
max) 


Group Control Table 
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data 1 - Set Selector = group control table entry selector. 
[7] - reserved. 
[6:0] - group control table entry selector. 


Intelligent Platform Management Interface Specification 


Parameter Parameter Data 

(optional, non-volatile. 

Present if BMC supports data 2 - 

automatic ICMB Group [7:6]- reserved 

Power Control. See ICMB [5] - Request/Force 

specification for details.) Ob = request control operation. A requested operation will only 


1b = 

[4] - 
Ob = 
1b = 

[3:0] - 


data 3: Group ID 0 (1-based) 
00h = unspecified 

= all groups 

data 4: Member ID 0 (0-based) 


FFh 


[7:5] - 
[4] - 


[3:0] - 


data 5: Group ID 1 (1-based) 
00h = unspecified 
FFh = all groups 

data 6: Member ID 1 (0-based) 


[7:5] - 
[4] - 


[3:0] - 


data 7: Group ID 2 (1-based) 
00h = unspecified 
FFh = all groups 

data 8: Member ID 2 (0-based) 


[7:5] - 
[4] - 


[3:0] - 


data 9: Group ID 3 (1-based) 
00h = unspecified 
FFh = all groups 

data 10: Member ID 3 (0-based) 


[7:5] - 
[4] - 


[3:0] - 


data 11: - Retries and Operation 


[7] - 
[6:4] - 


complete once the same operation has been requested for 
all control groups and all enabled control members for the 
given chassis. 

force control operation. A forced operation will occur 
regardless of whether the same operation has been 
requested for all control groups and all enabled control 
membership for the given chassis. 

Immediate/Delayed. Selects whether the BMC requests an 
immediate or delayed control operation. Note: whether this 
operation is initiated at the time the command is received is 
dependent on the request/force bit, see above. 

immediate control. BMC sends command that requests an 
immediate control operation. 

delayed control. BMC sends control command to request a 
delayed control operation. This is conditioned by the 
request/force bit. 

Channel Number (channel number for ICMB that group 
control operation is to be delivered over) 


reserved 

Ob = enable member ID check. 

1b = disable member ID check. 

member ID. ID of this chassis within specified group. (value 
is ignored if Group ID 0 = FFh) 


reserved 

Ob = enable member ID check. 

1b = disable member ID check!" 

member ID. ID of this chassis within specified group. (value 
is ignored if Group ID 1 = FFh) 


reserved 

Ob = enable member ID check. 

1b = disable member ID check". 

member ID. ID of this chassis within specified group. (value 
is ignored if Group ID 2 = FFh) 


reserved 

Ob = enable member ID check. 

1b = disable member ID check!" 

member ID. ID of this chassis within specified group. (value 
is ignored if Group ID 3 = FFh) 


reserved 

number of times to retry sending the command to perform 
the group operation [For ICMB, the BMC broadcasts a 
Group Chassis Control command] (1-based) 
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Parameter Data 


5h = 


[3:0] - operation 
Oh = 


power down. Force system into soft off (S4/S45) state. 
This is for ‘emergency’ management power down actions. 
The command does not initiate a clean shut-down of the 
operating system prior to powering down the system. 
power up. 

power cycle (optional). This command provides a power 
off interval of at least 1 second. 

hard reset. Some systems may accept this option even if 
the system is in a state (e.g. powered down) where resets 
are unavailable. 

pulse Diagnostic Interrupt. (optional) Pulse a version of a 
diagnostic interrupt that goes directly to the processor(s). 
This is typically used to cause the operating system to do 
a diagnostic dump (OS dependent). The interrupt is 
commonly an NMI on IA-32 systems and an INIT on Intel® 
Itanium™ processor based systems. 

Initiate a soft-shutdown of OS via ACPI by emulating a 
fatal overtemperature. (optional) 


Parameter # 
th 
OEM Parameters 96:127 
(optional. Non-volatile or 
volatile as specified by 
OEM) 


This range is available for special OEM configuration parameters. The 
OEM is identified according to the Manufacturer ID field returned by the 
Get Device ID command. 


1. The enable/disable member ID check bit controls whether a control request for the group is checked against the 
enabled members or not. If Member ID Check is disabled, then a control request to the group will automatically be 
‘logged’ for that group. Note, however, that the requested control state must match for all enabled groups in order 


for it to take effect. 


30.5 Set Last Processed Event ID Command 


This command is used to set the Record ID for the last event that was processed by system software. For test and 


debug purposes, it can also be used to set the Record ID for the last event processed by the BMC. See sections 


17.3, PEF Postpone Timer and 17.4.1, Last Processed Event Tracking for more information. The Last Processed 
Event ID value is automatically set to FFFFh whenever the SEL is cleared using the Clear SEL command. If the 


Delete SEL Entry command is used to either clear the SEL or delete the last event, software must set the Last 
Processed event manually by using the Set Last Processed Event ID command. 


Of the two Record IDs (software-processed or BMC-processed) PEF uses the Record ID for the most recent event 
that was added to the SEL as the indicator of events that have yet to be processed. Both the last BMC-processed 
and last software-processed IDs are kept in NV storage. 


Table 30-, Set Last Processed Event ID Command 


byte data field 
Request Data 


[7:1] - reserved. 
[0] - Ob = set Record ID for last record processed by software. 
1b = set Record ID for last record processed by BMC. 


Record ID. LS-byte first. 


2:3 
Response Data Completion Code 


81h = cannot execute command, SEL erase in progress 
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30.6 Get Last Processed Event ID Command 


This command is used to retrieve the Record ID for the last event that was processed by system software and the 
BMC. See sections 17.3, PEF Postpone Timer and 17.4.1, Last Processed Event Tracking for more information. 


Table 30-, Get Last Processed Event ID Command 
byte 


Request Data 
Response Data 


data field 


Completion Code 
81h = cannot execute command, SEL erase in progress 


Most recent addition timestamp. LS byte first. 


Record ID for last record in SEL. Returns FFFFh if SEL is empty. 


Last SW Processed Event Record ID. 


Last BMC Processed Event Record ID. Returns 0000h when event has been 
processed but could not be logged because the SEL is full or logging has 
been disabled. 


30.7 Alert Immediate Command 


This command is used to send an alert to the destination specified by the destination selector. The kind of alert 
that will be sent is determined by Destination Type associated with the destination. Alerts that are initiated via this 
command are never logged as events. This command is to support utilities or BIOS setup options that allow the 
user to test their alerting configuration for a given destination. The command can also be used by system software 
as a run-time mechanism to trigger the delivery of an alert. 


These alerts are not subject to the Page Blackout intervals, although an alert must complete before the next Alert 
Immediate command will be accepted. Alert Immediate commands are also rejected with an error completion code 
if an IPMI messaging session or automatic page is already in progress. 


Byte 
Request Data 


Table 30-, Alert Immediate Command 


data field 
Channel number. (This value is required to select which configuration 
parameters are to be used to send the Alert.) 
[7:4] - reserved 
[3:0] - Channel number. 
Note: BMC stores the ‘Alert immediate status’ for each channel that 
can send alert. 
Destination Selector/ Operation 
[7:6] - Operation 
00b = Initiate alert 
01b = Get Alert Immediate status 
10b = Clear Alert Immediate status (sets status to 00h) 
11b = reserved 
[5:4] - Reserved 
[3:0] - destination selector. Selects which alert destination should go to. 
Oh = use volatile destination info. 1h-Fh = non-volatile destination. 
Note: If Operation is ‘Get Alert Immediate status’ or ‘Clear Alert 
Immediate Status’ bits [3:0] are reserved. 
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3 Alert String Selector 

Selects which Alert String, if any, to use with the alert. 
[7] - 0b = don't send an Alert String 

1b = send Alert String identified by following string selector. 
[6:0] - string selector. 

000_0000b = use volatile Alert String. 

01h-7Fh = non-volatile string selector. 
The following “Platform Event Parameters” ( bytes 4:11) can be used to fill in 
the corresponding event data fields of a Platform Event Trap. When 
supported, all bytes (4:11) must be supplied. Implementation of this 
capability is OPTIONAL but highly recommended for IPMI v2.0 
implementations. See Table 29-, Event Request Message Fields, for 
specification of the individual fields. 


4 Generator ID 

5 EvMRev 

6 Sensor Type 

4 Sensor # 

8 Event Dir | Event Type 
9 Event Data 1 

10 | Event Data 2 

11 Event Data 3 


Response Data Completion Code. Generic codes, plus following command-specific 

completion codes: 

81h = Aler Immediate rejected due to alert already in progress. 

82h = Alert Immediate rejected due to IPMI messaging session active on this 

channel. 

83h = Platform Event Parameters (4:11) not supported. 

Following byte is only returned when Operation in request is set to “Get Alert 

Immediate status” 

Alert Immediate Status 

SMS can poll this status to determine present state of the immediate 
alert. 

00h = No status. 
Note: A BMC implementation is allowed (but not required) to abort 
the Alert Immediate command due to a channel parameter 
configuration, power, or reset state changes that occur while the 
Alert Immediate command is being processed. In which case the 
BMC will return the ‘no status’ state. 

Oih = Alert was Normal End. This will also be returned if one or more 
attempts failed, but the last attempt was successful. 

02h = “Call Retry” (Dial connection) retries failed. 

03h = Alert failed due to timeouts waiting for acknowledge on all retries. 

FFh = Alert by this command is in progress. Status pending. 
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30.8 PET Acknowledge Command 


This message is used to acknowledge a Platform Event Trap (PET) alert. PET alerts are SNMP Traps that are 
delivered by LAN or PPP alerting, see [PET] for more info. The PET Acknowledge message is an IPMI Request 
Message that is sent by the remote console that has received the trap. 


Note: The PET Acknowledge command does not require that an IPMI Messaging session be established with the 
BMC. It is in the same class as the Get Channel Authentication Capabilities command. In addition, if Alerting is 
enabled and the configuration parameters for the Alert Destination require the PET Alert to be acknowledged, the 
BMC will wait for and accept the PET Acknowledge command until the selected retry interval has expired, even if 
IPMI Messaging is not available according to the present Access Mode for the channel. For systems using Serial 
Port Sharing, the BMC will stay switched to the serial connector while waiting for the PET Acknowledge. 


Table 30-, PET Acknowledge Command 
byte data field 


Request Data 1:2 | Sequence Number. Value from the Sequence Number field of the PET. LS- 
byte first"), 
3:6 


Local Timestamp. Value from the Local Timestamp field of the PET. LS-byte 
first"), 


Event Source type. From corresponding field in the PET. 


Sensor Device. From corresponding field in the PET. 
Sensor Number. From corresponding field in the PET. 
Event Data 1:3. From corresponding field in the PET. 
Response Data Completion Code. 
1. Note The sequence number and local timestamp fields in the actual PET on the network are 


in network byte order, therefore filling in these values may require software to re-order the 
bytes as they get them from the trap. 
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31. System Event Log (SEL) Commands 


The System Event Log is a non-volatile repository for system events and certain system configuration information. 
The device that fields the commands to access the SEL is referred to as the System Event Log Device or SEL Device. 


Event Message information is normally written into the SEL after being received by the Event Receiver 
functionality in the Event Receiver Device. 


The SEL Device commands are structured in such a way that the SEL Device could actually be separated from the 
Event Receiver Device. In which case it would be the responsibility of the Event Receiver Device to send the 
appropriate ‘Add SEL Entry’ message directly to the SEL Device, or to pass the equivalent request through an 
intermediary. 


SEL Entries have a unique ‘Record ID’ field. This field is used for retrieving log entries from the SEL. SEL reading 
can be done in a ‘random access’ manner. That is, SEL Entries can be read in any order assuming that the Record ID 
is known. 


SEL Record IDs 0000h and FFFFh are reserved for functional use and are not legal ID values. Record IDs are 
handles. They are not required to be sequential or consecutive. Applications should not assume that SEL Record IDs 
will follow any particular numeric ordering. 


SEL Records are kept as an ordered list. That is, appending and deleting individual entries does not change the 
access order of entries that precede or follow the point of addition or deletion. 


31.1 SEL Device Commands 


The following table summarizes the commands that are required for implementing a System Event Log device. 
Note that this specification allows the System Event Log device to be implemented as a separate device from the 
Event Receiver and Event Generator devices. If this is done, it is up to the implementer to create the method by 
which Event Messages are passed from the Event Receiver Device to the System Event Log Device. Refer to 
Appendix G - Command Assignments for the specification of the Network Function and Command (CMD) values 
and privilege levels for these commands. 


Table 31-, SEL Device Commands 


Comma Section [om] 
Get SEL Allocation mo as oO 
Delete SELEnty  — Jae | 0 
[Set SEL Time UTC Offset — fb] o 
[GerAudiay Log Sus ma o 


Mandatory if multiple entities have overlapping access to the SEL If = 
mechanisms or conventions are defined that preclude this operation, then this 
command is optional. 

2. Either Add SEL Entry or Partial Add SEL Entry must be provided. Providing both is 
optional. 
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3. Set Auxiliary Log Status cannot be implemented without also supporting Get Auxiliary 
Log Status. However, Get Auxiliary Log Status is allowed to be implemented without 
Set Auxiliary Log Status. 

4. Mandatory if Set SEL Time UTC Offset command is implemented. 


31.2 Get SEL Info Command 


This command returns the number of entries in the SEL, SEL command version, and the timestamp for the most 
recent entry and delete/clear. The timestamp format is provided in section 0, 
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Timestamp Format. The Most Recent Addition timestamp field returns the timestamp for the last add or log 
operation, while the Most Recent Erase field returns the timestamp for the last delete or clear operation. 


These timestamps are independent of timestamps that may be returned by other commands, such as those returned 
by the Get SDR Repository Info command. The timestamp reflects when the most recent SEL add or erase 
occurred, not when the last add or erase occurred on the physical storage device. 


For example, the SEL Info Most Recent Addition timestamp would reflect the last time a new event was added to 
the SEL. This would be independent of the Most Recent Addition time for an SDR - even if the implementation 
elected to implement the SEL and SDR Repository in the same storage device. 


Table 31-, Get SEL Info Command 
byte data field 
Request Data 


Response Data 1 Completion Code 
81h = cannot execute command, SEL erase in progress 


SEL Version - version number of the SEL command set for this SEL Device. 
51h for this specification. 

(BCD encoded).BCD encoded with bits 7:4 holding the Least Significant 
digit of the revision and bits 3:0 holding the Most Significant bits. 


Entries LS Byte - number of log entries in SEL, LS Byte 
Entries MS Byte - number of log entries in SEL, MS Byte 


free space are available. 
7:10 | Most recent addition timestamp. LS byte first. 
Returns FFFF_FFFFh if no SEL entries have ever been made or if a 
component update or error caused the retained value to be lost. 


11:14 | Most recent erase timestamp. Last time that one or more entries were 
deleted from the log. LS byte first. 


15 Operation Support 
[7] - Overflow Flag. 1=Events have been dropped due to lack of space in 
the SEL. 
[6:4] - reserved. Write as 000 
[3] - 1b = Delete SEL command supported 
[2]- 1b = Partial Add SEL Entry command supported 


[1]- 1b = Reserve SEL command supported 
[0]- 1b = Get SEL Allocation Information command supported 


31.3 Get SEL Allocation Info Command 


Returns the number of possible allocation units, the amount of usable free space (in allocation units), the 
allocation unit size (in bytes), and the size of the largest contiguous free region (in allocation units). The 
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‘allocation unit size’ is the number of bytes in which storage is allocated. For example, if a 16-byte record is to be 
added, and the SEL has a 32-byte allocation unit size, then the record would take up 32-bytes of storage. 


The SEL implementation shall, at a minimum, support an allocation unit size of 216 bytes. 


Table 31-, Get SEL Allocation Info Command 
byte data field 


Request Data | - | 
Response Data SIE Completion Code 


Number of possible allocation units, LS Byte 

Number of possible allocation units, MS Bytes 

This number indicates whether the total number of possible allocation units is 
equal to, or some number less than the log size divided by the allocation unit 
size. 

0000h indicates ‘unspecified’. 


Allocation unit size in bytes, LS Byte. 0000h indicates ‘unspecified’. 
Allocation unit size in bytes, MS byte. 


5 

6 Number of free allocation units, LS Byte 

7 Number of free allocation units, MS Byte 
Largest free block in allocation units, LS Byte 
Largest free block in allocation units, MS Byte 


Maximum record size in allocation units. 


31.4 Reserve SEL Command 


This command is used to set the present ‘owner’ of the SEL, as identified by the Software ID or by the 
Requester’s Slave Address from the command. The reservation process provides a limited amount of protection 
on repository access from the IPMB when records are being deleted or incrementally read. 


The Reserve SEL command is provided to help prevent deleting the wrong record when doing deletes, to provide 
a mechanism to avoid clearing the SEL just after a new event has been received, and to prevent receiving 
incorrect data when doing incremental reads. 


The Reserve SEL command does NOT guarantee access to the SEL. That is, the case exists that a pair of 
requesters could vie for access to the SEL in such a manner that they alternately cancel the reservation that is held 
by the other - effectively ‘deadlocking’ each other. 


A ‘Reservation ID’ value is returned in response to this command. This value is required in other requests, such as 
the ‘Clear SEL’ command. These commands will not execute unless the correct Reservation ID value is provided. 


The Reservation ID is used in the following manner. Suppose an application wishes to clear the SEL. The 
application would first ‘reserve’ the repository by issuing a Reserve SEL command. The application would then 
check that all SEL entries have been handled prior to issuing the Clear SEL command. 


If an new event had been placed in the SEL after the records were checked, but before the Clear SEL command, it 
is possible for the event to be lost. However, the addition of a new event to the SEL causes the present 
Reservation ID to be ‘canceled’. This would prevent the Clear SEL command from executing. If this occurred, the 
application would repeat the reserve-check-clear process until successful. 


Table 31-, Reserve SEL Command 
byte data field 


Request Data 


Response Data 1 Completion Code 
81h = cannot execute command, SEL erase in progress 


Reservation ID, LS Byte 0000h reserved. 
Reservation ID, MS Byte 


422 


Intelligent Platform Management Interface Specification 


31.4.1 Reservation Restricted Commands 


A Requester must issue a ‘Reserve SEL’ command prior to issuing any of the following SEL commands. Note 
that the ‘Reserve SEL’ command only needs to be reissued if the reservation is canceled. These commands shall 
be rejected if the Requester’s reservation has been canceled. 


e Delete SEL Entry command 

e Clear SEL command 

e Get SEL Entry command (if ‘get’ is from an offset other than 00h) 
e Partial Add SEL Entry command 


If the given reservation has been canceled, a ‘reservation canceled’ completion code shall be returned in the 
response to the above commands. 


Note that the Record ID associated with a given record could change between successive offset 0 ‘Gets’ to that 

Record ID. For example, the first SEL Entry could change if the SEL were cleared and a new event came in. It 

is thus the responsibility of the device accessing the SEL to verify that the retrieved record information matches 
up with the ID information (timestamp, slave address, LUN, sensor ID, etc.) of the event record. 


31.4.2 Reservation Cancellation 
The SEL Device shall automatically cancel the present SEL reservation after any of the following events occur: 
e A SEL entry is added. 


e A SEL entry is deleted such that other Record IDs change. As a simplification, an implementation is 
allowed to cancel the reservation on any SEL entry deletion. 


e The SEL is cleared. 
e The SEL Device is reset (via hardware or Cold Reset command) 


e Anew ‘Reserve SEL’ command is received. 
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31.5 Get SEL Entry Command 


This command is used to retrieve entries from the SEL. The record data field in the response returns the 16 bytes 
of data from the SEL Event Record. 


Table 31-, Get SEL Entry 
byte data field 


1:2 | Reservation ID, LS Byte first. Only required for partial Get. Use 
0000h otherwise. 


3:4 | SEL Record ID, LS Byte first. 
0000h = GET FIRST ENTRY 
FFFFh = GET LAST ENTRY 


Offset into record 
Bytes to read. FFh means read entire record. 


Request Data 


Response Data 
81h = cannot execute command, SEL erase in progress. 
2 Next SEL Record ID, LS Byte first (return FFFFh if the record just 
returned is the last record.) 
Note: FFFFh is not allowed as the record ID for an actual record. 
Le the Record ID in the Record Data for the last record should not 
be FFFFh. 


3 
Record Data, 16 bytes for entire record 


1. The reservation ID should be set to 0000h for implementations that don’t implement the Reserve 
SEL command. 


1 Completion Code 
Return an error completion code if the SEL is empty. 


31.6 Add SEL Entry Command 


This command is provided to enable BIOS to add records to the System Event Log. Normally, the SEL Device 
and the Event Receiver Device will be incorporated into the same management controller. In this case, BIOS or 
the system SMI Handler adds its own events to the SEL by formatting an Event Message and transmitting it to the 
SEL Device, rather than by using this command. 


Records are added on after the last record in the SEL. The SEL Device adds the timestamp according to the SEL 
Record Type (see 31.6.1, SEL Record Type Ranges, following) when it creates the record. Thus, in some cases the 
timestamp bytes in the record data are ignored. However, ‘dummy’ timestamp bytes must still be present in the 
data. 


The record data field that is passed in the request consists of all bytes of the SEL event record. The Record ID 
field that is passed in the request is just a placeholder. The Record ID field that was passed in the request will be 
overwritten with a Record ID value that the SEL Device generates before the record is stored. Depending on the 
Record Type, the entry may also be automatically timestamped (see following section). If the entry is 
automatically timestamped, the SEL Device will also over-write the four bytes of the record’s timestamp field. 


Note: The normal mechanism for adding entries to the SEL is via an Event Request message to the Event 
Receiver device. 
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Table 31-, Add SEL Entry 
byte data field 


Request Data 1:16 | Record Data, 16 bytes. Refer to section 0, 
SEL Record Formats 


Response Data Completion Code. Generic, plus following command specific: 


80h = operation not supported for this Record Type 
81h = cannot execute command, SEL erase in progress 


Record ID for added record, LS Byte first. 


31.6.1 SEL Record Type Ranges 


The following lists the ranges used for SEL Record types: 


00h - BER Range reserved for standard SEL Record Types. As of this writing, only type 02h is defined. 
Records are automatically timestamped unless otherwise indicated. 


COh - DER Range reserved for timestamped OEM SEL records. These records are automatically 
timestamped by the SEL Device. 


EOh - FFh Range reserved for non-timestamped OEM SEL records. The SEL Device does not automatically 
timestamp these records. The four bytes passed in the byte locations for the timestamp will be 
directly entered into the SEL. 


31.7 Partial Add SEL Entry Command 


This command is a version of the Add SEL Entry command that allows the record to be incrementally added to the 
SEL. The Partial Add SEL Entry command must be preceded by a Reserve SEL command. The first partial add 
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must be to offset 0000h, and subsequent partial adds must be done sequentially, with no gaps or overlap between 
the adds. 


The add must be completed before any of its contents can be retrieved from the SEL. If the reservation is canceled 
before the add is completed, the information is discarded and the add must be redone starting at offset 0000h. 


When the Record Type directs the BMC to automatically timestamp the record, the BMC will set the timestamp 
when the last record is transferred. 


Note: The normal mechanism for adding entries to the SEL is via an Event Request message to the Event 
Receiver device. 


Table 31-, Partial Add SEL Entry Command 
byte data field 
Request Data 


3:4 | Record ID, LS Byte first. Used when continuing a partial add (non- 
zero offset into record). Use 0000h for Record ID otherwise. 
Offset into record. 


In progress. 
[7:4] - reserved 
[3:0] - in progress 
Oh = partial add in progress. 


th = last record data being transferred with this request 


SEL Record Data 


Response Data 1 Completion Code 
80h = Record rejected due to mismatch between record length in 
header data and number of bytes written. (Verifying the 


length is an optional operation for the management 
controller) 
81h = cannot execute command, SEL erase in progress 


1. The reservation ID should be set to 0000h for implementations that don’t implement the Reserve 
SEL command. 


31.8 Delete SEL Entry Command 


Table 31-, Delete SEL Entry 
byte data field 
Renuss Daia 
i SEL Record ID to delete, LS Byte first. 
0000h = FIRST ENTRY 
FFFFh = LAST ENTRY 
Response Data Completion Code - Generic plus following command specific: 
80h = operation not supported for this Record Type 
81h = cannot execute command, SEL erase in progress 


Record ID for deleted record, LS Byte first. 


1. The reservation ID should be set to 0000h for implementations that don't implement the Reserve 
SEL command. 
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31.9 Clear SEL Command 


The command ‘erases’ all contents of the System Event Log. Since this process may take several seconds, based 
on the type of storage device, the command also provides a means for obtaining the status of the erasure. 


Table 31-, Clear SEL 
byte data field 


Request Data 


AAh = initiate erase. 
OOh = get erasure status. 


Response Data EE Completion Code 


Erasure progress. 

[7:4] - reserved 

[3:0] - erasure progress 
Oh = erasure in progress. 
1h = erase completed. 


1. The reservation ID should be set to 0000h for implementations that don’t implement the Reserve 
SEL command. 


31.10 Get SEL Time Command 


This command returns the time from the SEL Device. This time is used by the SEL Device for Event 
Timestamping. 


Table 31-, Get SEL Time Command 
byte Ho field 
Request Data 


Response Data Lee Completion Code 


2:5 | Present Timestamp clock reading. LS byte first. See Section 0, 
Timestamp Format. 
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31.11 Set SEL Time Command 


This command initializes the time in the SEL Device. This time is used by the SEL Device for Event 
Timestamping. 


Table 31-, Set SEL Time Command 
byte data field 


Request Data 1:4 | Time in four-byte format. LS byte first. See Section 0, 
Timestamp Format. 


Response Data Completion Code 


31.11a Get SEL Time UTC Offset 


This command is used to retrieve the SEL Time UTC Offset that was set using the Set SEL Time UTC Offset 
command. See Set SEL Time UTC Offset command for additional information. 


Table 31-11a, Get SEL Time UTC Offset Command 
byte data field 
Request Data 


Response Data Completion Code 


16-bit, 2s-complement signed integer for the offset in minutes from 


UTC to SEL Time. LS-byte first. (ranges from -1440 to 1440) 


07FFh = ‘unspecified’. Interpret SEL time as local time. 


31.11b Set SEL Time UTC Offset 


This command initializes and retrieve a UTC offset (timezone) that is associated with the SEL Time (see the Set 
SEL Time command). The offset is the number of minutes difference between the local time zone and Universal 
Coordinated Time (UTC). 


If you know what the UTC time is, you get local time by adding the offset to the UTC time. To get UTC time 
from local time (SEL Time) you subtract the offset from the local time. For example, the offset for United States 
Pacific Standard Time is -8 (minus 8) hours. If the UTC time were 10am (10:00 hours), then Pacific Standard 
Time would be 2am (02:00 hours). The offset for Tokyo, Japan is +9 (plus 9), so if the UTC time were 10am, then 
the Tokyo, Japan time would be 7pm (19:00 hours). 


Note that the UTC offset varies with DAYLIGHT SAVINGS TIME. Therefore, if this is capability is used, 
software may be required to ensure the offset gets updated appropriately. 
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In order to retain backward compatibility with the original ‘local only’ definition of SEL Time, the UTC Offset is 
automatically reset to ‘unspecified’ whenever the Set SEL Time command is executed. Thus, the UTC Offset 
must be re-written after using the Set SEL Time command. 


Table 31-11b, Set SEL Time UTC Offset Command 
byte data field 


Request Data ; 16-bit, 25-complement signed integer for the offset in minutes from 
UTC to SEL Time. LS-byte first. (ranges from -1440 to 1440) 


07FFh = ‘unspecified’. Interpret SEL time as local time. 


Response Data Completion Code 


31.12 Get Auxiliary Log Status Command 


This command originated primarily to provide a mechanism that would allow remote software to know whether 
new information has been added to Machine Check Architecture (MCA) Log. that can be provided. The MCA 
Log is a storage area that can be implemented in Intel® Itanium™-based computer systems and holds information 
from an MCA Handler running from system firmware. 


For systems that lack MCA, the command can be used to return information about similar OEM-specified logs 
that may hold extended event information for the platform. Since such logs are usually central resources, this 
command will typically be implemented by a BMC in a host system, or the chassis controller in a managed 
peripheral chassis. 


Table 31-, Get Auxiliary Log Status Command 
byte data field 
Request Data Log Type 
[7:4] - reserved 
[3:0] - Log Type 
00h = MCA Log 
Oih = OEM 1 
02h = OEM 2 
all other = reserved 
Response Data Completion Code. An error completion code will be returned if the 
given log type is not supported. 
For Log Type = MCA Log : 
IPMI Timestamp for when last entry was added to MCA Log, per 
section 31, Timestamp Format. 
32-bit count of number of entries in MCA Log, LSByte first. 
FFFF_FFFFh = unspecified. 
For Log Type = OEM 1 or OEM 2: 
IPMI Timestamp for when last entry was added to log, per section 
31, Timestamp Format. 
OEM ID = three byte OEM IANA. IANA Enterprise Number for 
OEM/Organization that specifies the following log status bytes. Least 
significant byte first. 
Log status bytes per OEM identified by OEM ID 
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31.13 Set Auxiliary Log Status Command 


This command can be used by system software or firmware to set the status returned by the Get Auxiliary Log 
Status command. Some implementations may elect to implement solely private mechanism for setting this status, 
in which case this command may not be provided even if the Get Auxiliary Log Status is. 


Table 31-, Set Auxiliary Log Status Command 
byte data field 
Request Data Log Type 
[7:4] - reserved 
[3:0] - Log Type 
00h = MCA Log 
01h = OEM 1 
02h = OEM 2 
all other = reserved 
For Log Type = MCA Log : 

2:5 | IPMI Timestamp for when last entry was added to MCA Log, per 
section 31, Timestamp Format. 

6:9 | 32-bit count of number of entries in MCA Log, LSByte first. 
FFFF_FFFFh = unspecified. 

For Log Type = OEM 1 or OEM 2: 
IPMI Timestamp for when last entry was added to log, per section 
31, Timestamp Format. 

6:8 | OEM ID = three byte OEM IANA. IANA Enterprise Number for 
OEM/Organization that specifies the following log status bytes. Least 
significant byte first. 

9:16 | Log status bytes per OEM identified by OEM ID 


Response Data 1 Completion Code. An error completion code will be returned if the 
given Log Type is not supported. 
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32. SEL Record Formats 


The following sections present the record formats for SEL entries. Note that these are the ‘external’ specifications 
for the records. The actual storage format within the SEL Device implementation may be different. 


32.1 SEL Event Records 


The following table presents the format of SEL Event Records This is the stored information from Event 
Messages, as described in 29.4, Event Request Message Fields. 


Table 32-, SEL Event Records 


1 Record ID ID used for SEL Record access. The Record ID values 0000h and FFFFh have 
2 special meaning in the Event Access commands and must not be used as Record ID 
values for stored SEL Event Records. 
3 Record Type [7:0] - Record Type 
02h = system event record 
COh-DFh = OEM timestamped, bytes 8-16 OEM defined 
EOh-FFh = OEM non-timestamped, bytes 4-16 OEM defined 


Timestamp Time when event was logged. LS byte first. 


4 
5 
6 
7 


Generator ID RqSA & LUN if event was generated from IPMB. Software ID if event was generated 

from system software. 

Byte 1 

[7:1] - 7-bit PC . Slave Address, or 7-bit system software ID 

[0] Ob = ID is IPMB Slave Address 
1b = system software ID 

Byte 2 

[7:4] - Channel number. Channel that event message was received over. Oh if the 
event message was received via the system interface, primary IPMB, or 
internally generated by the BMC. (New for IPMI v1.5. These bits were reserved 
in IPMI v1.0) 

[3:2] - reserved. Write as 00b. 

[1:0] - IPMB device LUN if byte 1 holds Slave Address. 00b otherwise. 


EvM Rev Event Message format version (=04h for events in this specification, 03h for IPMI 
v1.0 Event Messages.) 
Note: the BMC must accept Platform Event request messages that are in IPMI v1.0 
format (EvMRev=03h) and log them as IPMI v1.5 / v2.0 Records by setting the 
EvMRev field to 04h and setting the Channel Number in the Generator ID field 
appropriately for the channel that the event was received from. 


| 11 | Sensor Type [| Sensor Type Code for sensor that generated the evet siz 
| 12 | Sensor# | Number of sensor that generated the evet | 
Event Dir | Event Dir 
Event Type [7] -Ob = Assertion event. 
1b = Deassertion event. 
Event Type 
Type of trigger for the event, e.g. critical threshold going high, state asserted, etc. 
Also indicates class of the event. E.g. discrete, threshold, or OEM. The Event Type 
field is encoded using the Event/Reading Type Code. See section 42.1, 
Event/Reading Type Codes. 
[6:0] - Event Type Code 


Event Data 1 Per Table 29-, Event Request Message Event Data Field Contents 
Event Data 2 Per Table 29-, Event Request Message Event Data Field Contents 
Event Data 3 Per Table 29-, Event Request Message Event Data Field Contents 
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32.2 OEM SEL Record - Type COh-DFh 


COh-DFh_ Range reserved for timestamped OEM SEL records. These records are automatically 
timestamped by the SEL Device. These records are entered via the Add SEL or Partial Add SEL 
commands. 


Table 32-, OEM SEL Record (Type COh-DFh) 


1 Record ID ID used for SEL Record access. The Record ID values 0000h and FFFFh have 
2 special meaning in the event access commands, and are not to be used as Record 
ID. values for stored SEL Event Records. 
ENG Li” EE 
Coh- DFh = OEM system event record 


4 Timestamp Time when event was logged (automatically added by SEL device). LS byte first. 
5 
2 


Manufacturer ID | Manufacturer ID (see Get Device ID command for definition) 


11:16 OEM Defined OEM Defined. This is defined according to the manufacturer identified by the 
Manufacturer ID field. 


32.3 OEM SEL Record - Type EOh-FFh 


EOh - FFh Range reserved for non-timestamped OEM SEL records. The SEL Device does not automatically 
timestamp these records. The four bytes passed in the byte locations normally used for the 
timestamp will be directly entered into the SEL. SEL viewer applications should not interpret 
byte positions 4:7 in this record as a timestamp. These records are entered via the Add SEL or 
Partial Add SEL commands. 


Note that an OEM ID is not part of this record. Since the record also has no mechanism for 
returning which controller or software logged the record, the OEM ID for this record is presumed 
to be the MFR ID from the Get Device ID command to the BMC. 


Table 32-, OEM SEL Record (Type EOh-FFh) 


Record ID | 1 TrRecodiD | ID used for SEL Record access. The Record ID values 0000h and FFFFh baue | 
special meaning in the event access commands, and are not to be used as Record 
ID values for stored SEL Event Records. 


Record Type [7:0] - Record Type 
EOh-FFh = OEM system event record 


OEM Defined. This is defined by the system integrator. 
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33. SDR Repository 


This section describes the logical SDR Repository Device, and the commands that are used to access the SDR 
Repository. This section also describes a companion set of functionality, the Internal Sensor Initialization Agent, 
that is part of a system that implements this platform and sensor instrumentation specification. 


The SDR Repository is intended to hold information indicating the set of management controllers, sensors, and FRU 
Devices that is expected to be in the system. Platform management often requires knowledge of what devices are 
supposed to be there, as opposed to what devices are detected. This is because an undetected device may be 
unintentionally absent, which in platform management usually constitutes a failure condition. 


For example, suppose the baseboard had connectors for five fans, but only the first four were supposed to be 
populated. The SDRs for the system would report four fan sensors, one for each of the first four connectors. This 
tells system management software that any fewer than four fans on the designated connectors would be an error 
condition. Thus, if the system user unintentionally disconnected a fan, system management software would see an 
error when it tried to get the fan status. Keeping this information also enables features that allow the platform 
management hardware itself to take automatic actions based on the ‘missing’ fan. 


The SDR records can be used to represent a custom configuration. Using the same example, suppose a system 
integrator wanted to attach only three fans to the baseboard, and use them on the last three connectors. The SDRs 
could be changed to report only three fans, and indicate they’re on the last three connectors. System management 
software only pays attention to sensors for which SDRs are present, thus by just adding, deleting, or modifying 
SDRs a system integrator can change the population of sensors within the constraint of the total available sensors 
built into the hardware. (I.e. you can’t ‘create’ a sensor that doesn’t pre-exist in hardware). 


SDRs are kept in a single, centralized Sensor Data Record Repository to simplify the ability for out-of-band 
applications to get information about the platform management subsystem. This eliminates the need for out-of-band 
applications, which may be over slow transports, to perform discovery actions. It also is a better mechanism to 
ensure that the information actually represents what’s supposed to be in the system, instead of just what was 
discovered. 


The SDR Repository implementation can be writable via standard IPMI commands, or it can be ‘read-only’. 
Supporting a writable SDR Repository provides a common way to support adding Sensor Data Records for 3rd party 
add-in devices and sensors, such as sensors provided by satellite management controllers on IPMB, Depending on 
the sensor implementation, writable SDRs can also be used to provide a non-volatile mechanism for changing the 
default behavior of sensors, such as whether they are scanning or generate events and what thresholds they use. 


33.1 SDR Repository Device 


The SDR Repository Device is a logical device that accepts and responds to SDR Repository commands. The 
SDR Repository Device isolated from most aspects of the data that is in an SDR. The SDR Device manages SDRs 
but does not interpret them or take action on the record contents. The exceptions to this is a small set of fixed 
fields that are used to identify the record and the record type. These fields are contained in the Record Header 
area of the Sensor Data Record. 


Another important set of fields are those that are identified as the Record Key fields. The combined information in 
these fields uniquely identifies the record contents. The Record Key fields are used for record content 
identification, while the Record ID field is used for record access. For example, a given instance of a sensor will 
always have the same Record Key information. The Record ID field, however can vary with time as records are 
added to and removed from the SDR Repository. 


The present specification only allows one SDR Repository device per system. For host systems that incorporate a 
BMC, the SDR Repository is implemented via the BMC. For peripheral chassis that use the ICMB, the device 
holding the SDR Repository is specified by the Chassis Capabilities command (refer to the Intelligent Chassis 
Management Bus Bridge specification). 
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33.2 Modal and Non-modal SDR Repositories 


There are two possible writable SDR Repository implementations: modal and non-modal. A non-modal SDR 
Repository can be written to at any time. Writing to the SDR does not impact the operation of other commands in 
the management controller. 


A modal SDR Repository is only updated when the controller is in an SDR Repository update mode. This 
provision is made to allow SDR information to be kept in non-volatile storage devices that may require lengthy 
write operations, or interfere with other controller operations when updated. For example, this could allow the 
SDR Repository to be stored in a FLASH device that also holds a portion of management controller code. A 
modal SDR Repository implementation would allow the functions associated with that code to be temporarily 
unavailable during the update process. 


An implementation that provides Modal SDR Repository Updates is not required to support non-modal SDR 
updates. Generic SDR update software should first issue a Get SDR Repository Info command to determine which 
type of update is supported. If the command returns ‘unspecified’, update software should first try a modal update 
by issuing an Enter SDR Update Mode command. If that command is accepted, it should perform the update in 
SDR Update Mode. If the command is not accepted, it should then attempt to perform a non-modal update. 


33.2.1 Command Support while in SDR Repository Update Mode 


The controller is only required to support a subset of its normal commands while it is in SDR Repository 
Update Mode. A completion code of DOh must be returned as the response to any commands that are rejected 
because the controller is in update mode. The list of commands that must be supported after entering SDR 
Repository Update mode are listed in the following table. Detailed information is provided in following 
sections. 


The update mode commands must be supported via the system interface to the BMC. If the controller provides 
an IPMB, it is recommended, but not mandatory, that the IPMB must remain active in SDR Repository Update 
mode. 


Table 33-, Mandatory SDR Update Mode Commands 
Command [Section] 


Either Add SDR or Partial Add SDR must be provided. Providing both is Spiona 
5 These commands are only accepted from the System Interface if SDR 
Repository Update Mode was entered via the System Interface, or are only 
accepted from the device that put the controller into SDR Repository Update 
mode. Other devices that try to issue these commands will receive a completion 
code indicating that SDR Repository Update is in progress. Reservation is not 
required for executing these commands in SDR Repository Update mode. 


33.3 Populating the SDR Repository 


Most systems are fundamentally static with respect to their platform management configuration once the system 
integrator has put the system together. Thus, the typical model for an implementation that supports a writable 
SDR Repository is that it is manually updated using a utility or other piece of software if the platform 
management configuration is changed in the field. 


For example, suppose a system could be upgraded to accept a new RAID backplane that had extra fans and 
temperature sensors. Part of the upgrade process would be to run a utility, supplied by the system integrator, that 
updated the SDR Repository with the new SDRs. 
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33.3.1 SDR Repository Updating 


An SDR Repository implementation is not required to implement the Delete SDR command. This means that 
random updates of individual records is not supported. In this case, updating the SDR Repository requires 
reading out the SDR Repository, updating the copy, clearing the SDR Repository, and writing the updated 
records in. Note that this approach works for all implementations, and helps avoid potential issues with 
fragmentation of the SDR Repository. 


33.4 Discovering Management Controllers and Device SDRs 


IPMI includes the capability for allowing system software to discover management controllers. The responsibility 
of detecting and integrating new devices is left to system software. This is done to avoid placing additional 
complexity in BMC firmware, and to allow the discovery and integration policy to be more flexible and 
sophisticated. 


A system can be created that allows new management controllers and SDRs to automatically be discovered and 
integrated into the SDR Repository. The following steps outline this process: 


1. System management software uses the Broadcast Get Device ID command to discover all management 
controllers on the IPMB. It does this by repeatedly issuing the Broadcast Get Device ID, incrementing the 
second byte in the message to select different management controller slave addresses. The software only 
needs to go through the slave addresses that are assignable to IPMB devices (refer to the IPMB Address 
Allocation specification.) System management software can go through this process when it initializes, or, 
preferably, run this as a ‘background’ process that scans for new devices during run-time. 


2. System management software reads the SDRs and gets a list of the known management controllers from the 
Management Controller Device Locator records. For each discovered device, system management software 
checks to see if the device is one of the known devices or not. If the device has a corresponding Management 
Controller Confirmation record, this record can be used to verify that a different type or instance of controller 
didn’t wind up at the address of a previously present controller. 


3. For each newly discovered device, system management software would typically prompt the system user for 
whether the device should be integrated or not. (For ‘missing’ devices, the system user would be notified of 
the change). If the device supports Device SDRs, system management software would be able to read the 
SDRs from the device and write them to the SDR Repository. If the device didn’t include Device SDRs, the 
software would likely prompt the user for update software supplied by the system integrator or device 
provider. Note that the management controllers now include information such as the manufacturer ID, that 
can be an aid to creating useful prompts for this kind of information. 


33.5 Reading the SDR Repository 


An application that retrieves records from the SDR Repository must first read them out sequentially. This is 
accomplished by using the Get SDR command to retrieve the first SDR of the desired type. The response to this 
command returns the requested record and the Record ID of the next SDR in sequence in the repository. Note that 
Record IDs are not required to be sequential or consecutive. Applications should not assume that SDR Record 
IDs will follow any particular numeric ordering. 


The application retrieves succeeding records by issuing a Get SDR command using the ‘next’ Record ID that was 
returned with the response of the previous Get SDR command. This is continued until the ‘End of Records’ ID is 
encountered. 


Once the application has read out the desired records, it can then randomly access the records according to their 
Record ID. An application that seeks to access records randomly must save a data structure that retains the Record 
Key information according to Record ID. 


Since it is possible for Record IDs to change with time, it is important for applications to first verify that the 
Record Key information matches up with the retrieved record. If the Record Key information doesn’t match, then 
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the Record ID is no longer valid for that Record Key, and the SDR Records must again be accessed sequentially 
until the record that matches the Record Key is located. 


An application can also tell whether records have changed by examining the ‘most recent addition’ timestamp 
using the Get SDR Repository Info command. 


If record information has changed, an application does not need to list out the entire contents of all records. The 
Get SDR command allows a partial read of the SDR. Thus, an application can search for a given Record Key by 
just retrieving that portion of the record. 


33.6 Sensor Initialization Agent 


The Sensor Initialization Agent is not a logical device, but rather a collection of functions and services that are 
specific to handling SDR information. Unlike the SDR Repository Device, the Sensor Initialization Agent works 
directly with the content of SDRs, in particular, the Sensor Data Records and Device Locator Records. 


The Initialization Agent utilizes the SDR information for sensor and IPMB Device initialization during system 
startup. The Initialization Agent knows how to interpret Sensor Data Records and is directed by the ‘init required’ 
fields to load thresholds to sensors that have the ‘threshold initialization required’ bit set in their SDR record. 
Other bits in the record direct the agent to enable sensors/devices that come up with sensors and/or events 
disabled. 


The Initialization Agent Function normally runs whenever the system powers up, and upon system Hard Resets. 
This ensures that the sensor subsystem and threshold values will be re-initialized in response to ‘push-button’ 
hardware resets. It is also recommended that the Initialization Agent function run when the BMC first receives 
standby power. 


Note that in systems that implement power-management, System Management Software may need to take 
additional steps to restore intermediate settings after the system has ‘woken up’. 


33.6.1 System Support Requirements for the Initialization Agent 


The BMC requires information about when the system has been powered up, hard reset, or warm *ctrl-alt-del” 
reset. This information is needed to trigger the Initialization Agent function. The mechanism for accomplishing 
this is implementation-dependent. Two common ways to provide this information are via hardware signals to 
the BMC, or via a BMC-specific application command from BIOS. A combination of the two can also be used. 
For example, a hardware signals could be used to indicate when the system is hard-reset, while a command 
from BIOS could indicate warm ‘ctrl-alt-del’ resets. 


33.6.2 IPMI and ACPI Interaction 


The Initialization Agent restores ‘power-on default’ threshold values and event enable settings. In order to 
provide consistent operation, the initialization agent takes the same actions on ‘warm’ (e.g. ctrl-alt-del) resets. 


In a system that has ACPI, the platform management subsystem cannot generally distinguish between power-up 
from an S5 ‘OFF’ state and power-up from an S4 ‘Suspend-to-disk’ sleep state. When the system wakes from 
an S4 state, system management software should recognize this condition so that it can restore any ‘volatile’ 
settings that it may have gotten reset by the Initialization Agent. 


For other sleep states (S1-S3), the management controllers should retain their settings and the Initialization 
Agent should not be run on wake. If a management controller (other than the BMC) gets powered down in S1- 
S3, that controller is responsible for retaining the last settings that were written to it by system software. 


System management software should also be aware of ACPI interaction with the watchdog timer. The watchdog 
timer does not automatically stop counting down when the system enters an S1-S3 sleep state. If the watchdog 
timer is being used as an OS Watchdog, system management software should use support in the operating 
system to schedule a ‘wake event’ such that system management software can run and reload the timer before it 
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expires. Alternatively, system management software could shut down the timer upon receiving a notification of 
entry into a sleep state, but that would reduce the value of using a watchdog timer to monitor OS or system 
software health. 


33.6.3 Recommended Initialization Agent Steps 


1. 
2. 


Initialize any BMC internal functions that are required by BIOS during POST. 


Disable the Event Receiver function for events received from any interface but the system interface, or from 
BMC internal sensors that require initialization. The BMC should accept event messages from BIOS while the 
initialization agent is running. The implementation may elect to accept BMC internal event messages from 
sensors that do not require initialization. It is recommended that any events related to the initialization agent 
operation are logged during the initialization agent process - but they may be collected and logged at its 
conclusion. 


Scan the SDR repository for Management Controller Device Locator records. Collect a list of the addresses of 
management controllers that require initialization. (A field in the Management Controller Device Locator record 
indicates whether the management controller requires initialization, and if so, whether event messaging should 
be enabled after the controller has been initialized.) This list should include the BMC itself. 


For each Management Controller in the list, turn off Event Generation by using the Set Event Receiver 
command to set the Event Receiver. If the Management Controller does not respond to the Set Event Receiver 
command, take it off the list. 


a) Scan the SDR Repository for Type Olh & Type 02h SDRs. For each encountered: 


b) Check the Device Owner ID to see if the sensor belongs to the BMC or one of the other management 
controllers in the list. If it does not, go on to the next record. 


c) Itis possible that a management controller may have other actions that it takes on an event, thus it is 
important to disable event scanning before setting thresholds and hysteresis. Check the Sensor Capabilities 
field to see if per-sensor or per-threshold/per-state disable is supported. If it is, then use the Set Sensor 
Event Enable command to disable scanning and event messages per the SDR. 


d) Set the sensor type, sensor thresholds, and hysteresis as directed by the SDR using the Set Sensor Type, Set 
Sensor Thresholds, and Set Sensor Hysteresis commands. 


e) Use the Set Sensor Event Enable command to enable scanning and event generation per the SDR. Go on to 
next SDR. 


Enable the BMC Event Receiver function for the IPMB and other interfaces. 


For each management controller in the list, enable event message generation or leave it disabled (A field in the 
Management Controller Device Locator record indicates whether event messaging should be enabled after the 
controller has been initialized.) 


33.7 SDR Repository Device Commands 


The following sections describe the commands that an SDR Repository Device provides for accessing the SDR 
Repository. 


The commands are designed to simplify the SDR Repository device’s implementation by ‘pushing back’ 
intelligence to higher-level software where possible. The SDR Repository device is not intended to be a ‘database’ 
engine. Thus, the SDR access commands do not include automatic search functions. It is recommended that an 
application read the SDR Repository into a RAM buffer and work from that copy (keeping track of the SDR 
Timestamp to check for possible changes to the SDR Repository). The general procedure for reading SDRs from 
the SDR Repository is described under the Get SDR command. 
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As with Event Messages, it is also the intent that the commands are designed so that the SDR Repository Device 
is isolated from needing to know the content and format of the SDR records themselves. 


Refer to Appendix G - Command Assignments for the specification of the Network Function and Command 
(CMD) values and privilege levels for these commands. 


Table 33-, SDR Repository Device Commands 


Comman — Section | Om | 
Get SDR Repository Info 
Get SDR Repository Allocation Info 33.10 | O | 
Reserve SDR Repository 33.11 
Get SDR 33.12 | M5 | 

M 
O 
O 


asn sata | Mi] 


Enter SDR Repository Update Mode 33.19 


om | 
ME] 
[Get SDR Repository Time — 8347 [omr 
KOGE 
Co 
[Exit SDR Repository Update Mode 3320 oer] 


MEI 
MI] 
OP 

ME 
i i /MEI 

Kë 
| M 

= 

OR Rep = 


Run Initialization Agent 33.21 | OM | 


If a writable Sensor Data Record Repository is implemented, either Add SDR or Partial Add 
SDR must be provided via the system interface. Providing both via the system interface is 
optional. For the IPMB, the Add SDR and Partial Add SDR commands are optional. 

2. Ifthe SEL Device and SDR Repository Device are implemented in separate controllers, 
then both these commands are Mandatory for the SDR Repository Device. If the SDR 
Repository Device shares the same controller as the SEL Device (This is normally 
indicated in the IPM Device Support field of the Get Device ID command), then the SDR 
device uses the SEL Device’s Timestamp Clock. In this case, the Get SDR Repository 
Time command is optional, and the Set SDR Repository Time command is not used. 

3. Support for both these commands is mandatory if a modal SDR Repository is implemented. 
The Enter SDR Repository Update Mode command is mandatory when in ‘operational’ 
mode, while the Exit SDR Repository Update Mode is mandatory when in ‘update’ mode. 

4. Highly recommended. This supports utilities that can update the SDRs during run-time. 
Without this, a system reset will need to be performed to cause the initialization agent to 
run. 

5. Mandatory if writable Sensor Data Record Repository is implemented. A reservation field of 

0000h is passed to these commands when in SDR Repository Update Mode. 


1 


33.8 SDR ‘Record IDs’ 


In order to generalize SDR access, Sensor Data Records are accessed using a ‘Record ID’ number. There are a 
fixed number of possible Record IDs for a given implementation of the SDR Repository. 


The most common implementation of ‘Record IDs’ is as a value that translates directly to an ‘index’ or ‘offset’ 
into the SDR Repository. However, it is also possible for an implementation to provide a level of indirection, and 
implement Record IDs as ‘handles’ to the Sensor Data Records. 


Record ID values may be ‘recycled’. That is, the Record ID of a previously deleted SDR can be used as the 
Record ID for a new SDR. The requirement is that, at any given time, the Record IDs are unique for all SDRs in 
the repository. 


Record IDs can be reassigned by the SDR Repository Device as needed when records are added or deleted. An 
application that uses a Record ID to directly access a record should always verify that the retrieved record 
information matches up with the ID information (slave address, LUN, sensor ID, etc.) of the desired sensor. An 
application that finds that the SDR at a given ‘Record ID’ has moved will need to re-enumerate the SDRs by 
listing them out using a series of Get SDR commands. Note that it is not necessary to read out the full record data 
to see if the Record ID for a particular record has changed. Software can determine whether a given record has 
been given a different Record ID by examining just the SDR’s header and record key bytes. 
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33.9 Get SDR Repository Info Command 


This command returns the SDR command version for the SDR Repository. It also returns a timestamp for when 
the last ADD, DELETE, or CLEAR occurred. The Most Recent Addition timestamp field returns the timestamp 
for the last addition operation, while the Most Recent Erase field returns the timestamp for the last delete or clear 
operation. 


These timestamps are independent of timestamps that may be returned by other commands, such as those returned 
by the Get SEL Info command. The timestamp reflects when the most recent SDR Repository add or erase 
occurred, not when the last add or erase occurred on the physical storage device. 


For example, the SDR Repository Info Most Recent Addition timestamp would reflect the last time a new record 
was added to the SDR Repository. The SDR Repository’s most recent addition timestamp is always independent 
of the most recent addition time for the SEL - even if the SEL and SDR Repository are implemented in the same 
physical storage device. 


Table 33-, Get SDR Repository Info Command 
byte data field 


Request Data | -|- ooo ü UO 
Response Data Completion Code 


SDR Version - version number of the SDR command set for the SDR Device. 
51h for this specification. (BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits.) 


Record count LS Byte - number of records in the SDR Repository 
| 4 | Record count MS Byte - number of records in the SDR Repository 


5:6 | Free Space in bytes, LS Byte first. 0000h indicates ‘full’, FFFEh indicates 
64KB-2 or more available. FFFFh indicates ‘unspecified’. 


7:10 | Most recent addition | Most recent addition timestamp. LS byte first. = LS | Most recent addition timestamp. LS byte first. = first. 
11:14 | Most recent erase (delete or clear) timestamp. LS byte first. 


11b = both modal and non-modal SDR Repository Update supported 
reserved. Write as Ob 

1b=Delete SDR command supported 

1b=Partial Add SDR command supported 

1b=Reserve SDR Repository command supported 

1b=Get SDR Repository Allocation Information command supported 


5 | Operation Support 
[7]- Overflow Flag. 1=SDR could not be written due to lack of space in the 
SDR Repository. 
[6:5] - OOb = modal/non-modal SDR Repository Update operation unspecified 
01b = non-modal SDR Repository Update operation supported 
10b = modal SDR Repository Update operation supported 


33.10 Get SDR Repository Allocation Info Command 


Returns the number of possible allocation units, the amount of usable free space (in allocation units), the 
allocation unit size (in bytes), and the size of the largest contiguous free region (in allocation units). The 
‘allocation unit size’ is the number of bytes in which storage is allocated. For example, if a 20-byte record is to be 
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added, and the SDR Repository has a 16-byte allocation unit size, then the record would take up 32-bytes of 
storage. 


The SDR Repository implementation shall, at a minimum, provide an allocation unit size of 216 bytes and a 
“maximum record size” supporting a record of = 64 bytes. 


Software should assume an allocation unit size of 16-bytes if this command is not implemented. 


Table 33-, Get SDR Repository Allocation Info Command 
byte data field 


Request Data | -o o üO 
Response Data Em Completion Code 


Number of possible allocation units, LS Byte 

Number of possible allocation units, MS Bytes 

This number indicates whether the total number of possible allocation units is 
equal to, or some number less than the log size divided by the allocation unit 
size. 

0000h indicates ‘unspecified’. 


Allocation unit size in bytes. 0000h indicates ‘unspecified’. 
5 
6 Number of free allocation units, LS Byte 
7 Number of free allocation units, MS Byte 
Largest free block in allocation units, LS Byte 
Largest free block in allocation units, MS Byte 


Maximum record size in allocation units. 


33.11 Reserve SDR Repository Command 


This command is used to set the present ‘owner’ of the repository, as identified by the ‘Software ID’ or by the 
Requester’s Slave Address from the command. The reservation process provides a limited amount of protection 
on repository access from the IPMB when records are being deleted or incrementally read. 


The Reserve SDR Repository command is provided to help prevent deleting the wrong record when doing deletes, 
and to prevent receiving incorrect data when doing incremental reads. 


The Reserve SDR Repository command does NOT guarantee access to the SDR Repository. That is, the case 
exists that a pair of requesters could vie for access to the SDR in such a manner that they alternately cancel the 
reservation that is held by the other - effectively ‘deadlocking’ each other. 


A ‘Reservation ID’ value is returned in response to this command. This value is required in other requests, such as 
the ‘Delete SDR’ command. These commands will not execute unless the correct Reservation ID value is 
provided. 


The Reservation ID is used in the following manner. Suppose an application wishes to delete a particular record. 
The application would first ‘reserve’ the repository by issuing a Reserve SDR Repository command. The 
application would then read the header and key information from the record to verify that it has the correct Record 
ID for the record. Assuming this is correct, the application would then issue a Delete SDR command using the 
Reservation ID and Record ID as parameters. 


If an event had occurred that changed the Record IDs after the header and key information was read but before the 
Delete SDR command, the Delete SDR command could be issued with the Record ID for the wrong record. 
However, events that change Record IDs for any existing records cause the present Reservation ID to be 
‘canceled’. This prevents software from using an out-of-date Record ID to access a record. For example, it would 
prevent the Delete SDR command from executing and deleting the wrong record in case a given Record ID was 
reassigned to a different record. 
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Table 33-, Reserve SDR Repository Command 
byte data field 


Request Data | - | ooo ü O 
Response Data Completion Code 


Reservation ID, LS Byte 
Reservation ID, MS Byte 


33.11.1 Reservation Restricted Commands 


A Requester must issue a ‘Reserve SDR Repository’ command prior to issuing any of the following SDR 
Repository commands. Note that the ‘Reserve SDR Repository’ command only needs to be reissued if the 
reservation is canceled. These commands shall be rejected if the Requester’s reservation has been canceled. 


e Delete SDR command 

e Clear SDR Repository command 

e Get SDR command (if a partial read) 
e Partial Add SDR command 


If the given reservation has been canceled, a ‘reservation canceled’ completion code shall be returned in the 
response to the above commands. This is explained further in the next section. 


Note that since Record IDs could change between offset 0 ‘Gets’ of a given record, it is the responsibility of the 
device accessing the repository to verify that the retrieved record information matches up with the ID 
information (slave address, LUN, sensor ID, etc.) of the desired sensor. 


33.11.2 Reservation Cancellation 


The SDR Repository Device shall automatically cancel the present SDR Repository reservation after any of the 
following events occur: 


e An SDR record is added using the Add SDR command such that other Record IDs change. As a 
simplification, an implementation is allowed to cancel the reservation on any SDR record add. 


e An SDR record is deleted such that other Record IDs change. As a simplification, an implementation is 
allowed to cancel the reservation on any SDR record deletion. 


e The SDR Repository is cleared. 
e The SDR Repository Device is reset (via hardware or Cold Reset command) 
e Anew ‘Reserve SDR Repository’ command is received. 


An error completion code will be returned if an attempt is made to execute a command that requires a 
reservation ID, but the reservation ID used is not valid or current. 


33.12 Get SDR Command 


Returns the sensor record specified by ‘Record ID’. The command also accepts a ‘byte range’ specification that 

allows just a selected portion of the record to be retrieved (incremental read). The Requester must first reserve the 
SDR Repository using the ‘Reserve SDR Repository’ command in order for an incremental read to an offset other 
than 0000h to be accepted. (It is also recommended that an application use the Get SDR Repository Info command 
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to verify the version of the SDR Repository before it sends any other SDR Repository commands. This is 
important since the SDR Repository command format and operation can change between versions.) 


If ‘Record ID’ is specified as 0000h, this command returns the Record Header for the ‘first? SDR in the 
repository. FFFFh specifies that the ‘last? SDR in the repository should be listed. If ‘Record ID’ is non-zero, the 
command returns the information from the matching record, and the Record ID for the next SDR in the repository. 


An application that wishes to retrieve the full set of SDR Records must first issue the Get SDR starting with 
0000h as the Record ID to get the first record. The Next Record ID is extracted from the response and this is then 
used as the Record ID in a Get SDR request to get the next record. This is repeated until the ‘Last Record ID’ 
value (FFFFh) is returned in the ‘Next Record ID’ field of the response. 


A partial read from offset 0000h into the record can be used to extract the header and associated ‘Key Fields’ for 
the specified Sensor Data Record in the SDR Repository. An application can use the command in this manner to 
get a list of what records are in the SDR and to identify the instances of each type. It can also be used to search for 
an particular sensor record. 


Note: to support future extensions, applications should check the SDR Version byte prior to interpreting any of 
the data that follows. 


The application issuing ‘Get SDR’ commands with a non-zero value for the Offset into record field must first 
reserve the SDR Repository by issuing a ‘Reserve SDR Repository’ command. 


If you issue a Get SDR command (storage 23h) with a ‘bytes to read’ size of 'FFh' - meaning read entire record. A 
value of 'FFh' will cause an error in most cases, since SDRs are bigger than the buffer sizes for the typical system 
interface implementation. The controller therefore returns an error completion code if the number of record bytes 
exceeds the maximum transfer length for the interface. The completion code CAh that indicates that the number 
of requested bytes cannot be returned. Returning this code is recommended, although a controller could also 
return an 'FFh' completion code. In either case, the algorithm for handling this situation is to "default to using 
partial reads if the read entire record! operation fails" (that is, if you get a non-zero completion code). 


Table 33-, Get SDR Command 
byte data field 


Request Data 1 Reservation ID. LS Byte. Only required for partial reads with a non- 
zero 'Offset into record field. Use 0000h for reservation ID 


otherwise. 


Reservation ID. MS Byte. 
Record ID of record to Get, LS Byte 
Record ID of record to Get, MS Byte 


5 
— 6 |Bytestoread.FFhmeansreadentveresod. | 
Response Data 
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33.13 Add SDR Command 


This command adds the specified sensor record to the SDR Repository and returns its ‘Record ID’. The data 
passed in the request must contain the SDR data in its entirety. 


Table 33-, Add SDR Command 
byte data field 


Request Data 
Response Data 


33.14 Partial Add SDR Command 


This command is a version of the Add SDR command that allows the record to be incrementally added to the 
repository. The Partial Add SDR command must be preceded by a ‘Reserve SDR Repository’ command. The first 
partial add must be to offset 0000h, and partial adds must be done sequentially, with no gaps or overlap between 
the adds. 


The add must be completed before any of its contents can be retrieved from the SDR Repository. If the 
reservation is canceled before the add is completed, the information is discarded and the add must be redone 
starting at offset 0000h. 


Software should assume an allocation unit size of 16-bytes if the Get SDR Allocation Info command is not 
supported. 


Table 33-, Partial Add SDR Command 
byte data field 


Request Data Reservation ID, LS Byte. 
Reservation ID, MS Byte. 


3 Record ID, LS Byte for continuing partial add. Use 0000h for Record 
ID otherwise. 

4 Record ID, MS Byte for continuing partial add. Use 0000h for 
Record ID otherwise. 


Offset into record. 


In progress. 
[7:4] - reserved 
[3:0] - in progress 
Oh = partial add in progress. 
th = last record data being transferred with this request 


SDR Record Data 


Response Data Completion Code. Generic, plus following command-specific: 
80h = Record rejected due to mismatch between record length in 
header data and number of bytes written. (Verifying the 
length is an optional operation for the management 
controller) 


Record ID for added record, LS Byte 
Record ID for added record, MS Byte 
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33.15 Delete SDR Command 


Deletes the sensor record specified by ‘Record ID’. The Requester’s ID and the ‘Reservation ID’ must also match 
the present ‘owner’ of the SDR Repository. 


Table 33-, Delete SDR Command 
byte data field 


Request Data 


Response Data Completion Code 
Record ID for deleted record, LS Byte 
Record ID for deleted record, MS Byte 


33.16 Clear SDR Repository Command 


Clears all records from the SDR Repository and reinitializes the SDR Repository ‘subsystem’. Mainly a 
development and production aid, use of this command should be generally avoided in utilities and system 
management software. The Requester’s ID and Reservation ID information must also match the present ‘owner’ 
of the SDR Repository. 


Table 33-, Clear SDR Repository Command 
byte data field 


Request Data 
AAh = initiate erase. 
CS 00h = get erasure status. 
Response Data 
2 


Erasure progress. 


[7:4] - reserved 

[3:0] - erasure in progress 
Oh = erasure in progress. 
1h = erase completed. 


33.17 Get SDR Repository Time Command 


This command returns the time from the SDR Repository Device. This time is used by the SDR Repository 
Device for tracking when changes to the SDR Repository have been made. The time keeping format is specified 
in Section 0, 
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Timestamp Format. 


A device that contains both a logical SEL device and an SDR Repository device can elect to implement just a 
single Timestamp Clock, in which case, the Set SDR Repository command shall not be used. Instead, the Set SEL 
Time command will be used for setting the time, and the Get SDR Repository Time and Get SEL Time commands 
shall effectively return the same time values. 


Table 33-, Get SDR Repository Time Command 
byte data field 


Request Data 


Response Data Completion Code 
Time in four-byte format. LS byte first. 


33.18 Set SDR Repository Time Command 


This command initializes the time in the SDR Repository Device. This time is used by the SDR Device for 
tracking when SDR Repository changes have been made. The time keeping format is specified in Section 0, 
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Timestamp Format. 


A device that contains both a logical SEL device and an SDR Repository device can elect to implement just a 
single Timestamp Clock, in which case, the Set SDR Repository command shall not be used. Instead, the Set SEL 
Time command will be used for setting the time, and the Get SDR Repository Time and Get SEL Time commands 
shall effectively return the same time values. 


Table 33-, Set SDR Repository Time Command 
byte data field 


Request Data Time in four-byte format. LS byte first. 
Response Data Completion Code 


33.19 Enter SDR Repository Update Mode Command 


Table 33-, Enter SDR Repository Update Mode Command 
byte data field 


Request Data | - | 


Response Data Completion Code 


33.20 Exit SDR Repository Update Mode Command 


Table 33-, Exit SDR Repository Update Mode Command 
byte data field 


Request Data | - | 


Response Data Completion Code 


33.21 Run Initialization Agent Command 


This command can be used to cause the Initialization Agent to run. The command can be used to check the status 
of the Initialization Agent as well. 


Table 33-, Run Initialization Agent 
byte data field 
Request Data [7:1] -reserved 
[0] - 1b = run initialization agent 
Ob = get status of initialization agent process 


Response Data Completion Code 


2 1[7:1] reserved 
[0] - 1b = initialization completed 
Ob = initialization in progress 
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34. FRU Inventory Device Commands 


The following sections describe the FRU (Field Replaceable Unit) Inventory Device format and access commands. 
The FRU Inventory data contains information such as the serial number, part number, asset tag, and short 
descriptive string for the FRU. The contents of a FRU Inventory Record are specified in the Platform Management 
FRU Information Storage Definition. 


The FRU Inventory Device is a ‘logical’ device. It is not necessarily implemented as a separate physical device, 
though it can be. For example, the device that contains the SDR Repository Device also typically also holds FRU 
Inventory’ information for the main system board and chassis. On the other hand, there may be a separate FRU 
Inventory device that provides access to the FRU information for a replaceable module such as a Memory Module. 
Refer to Appendix G - Command Assignments for the specification of the Network Function and Command (CMD) 
values and privilege levels for these commands. 


Table 34-, FRU Inventory Device Commands 


[command] Section [ OM 
Get FRU Inventory Area Info 


O/M = Option/Mandatory for FRU Inventory Devices. 


34.1 Get FRU Inventory Area Info Command 
Returns overall the size of the FRU Inventory Area in this device, in bytes. 


Table 34-, Get FRU Inventory Area Info Command 
byte data field 


Request Data 
Response Data 


4 7:1] - reserved 
[0] Ob = Device is accessed by bytes, 1b = Device is accessed by words 
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34.2 Read FRU Data Command 


The command returns the specified data from the FRU Inventory Info area. This is effectively a ‘low level’ direct 
interface to a non-volatile storage area. This means that the interface does not interpret or check any semantics or 
formatting for the data being accessed. The offset used in this command is a ‘logical’ offset that may or may not 
correspond to the physical address used in device that provides the non-volatile storage. For example, FRU 
information could be kept in FLASH at physical address 1234h, however offset 0000h would still be used with 
this command to access the start of the FRU information. IPMI FRU device data (devices that are formatted per 
[FRU]) as well as processor and DIMM FRU data always starts from offset 0000h unless otherwise noted. 


Note that while the offsets are 16-bit values, allowing FRU devices of up to 64K words, the count to read, count 
returned, and count written fields are only 8-bits. This is in recognition of the limitations on the sizes of messages. 
For example, as of this writing, IPMB messages are limited to 32-bytes total. 


Table 34-, Read FRU Data Command 
byte data field 


Request Data FRU Device ID. FFh = reserved. 
FRU Inventory Offset to read, LS Byte 


3 FRU Inventory Offset to read, MS Byte 
Offset is in bytes or words per device access type returned in the 


Get FRU Inventory Area Info command. 


4 Count to read --- count is ‘1’ based 


Response Data Completion code. Generic, plus following command specific: 
81h = FRU device busy. The requested cannot be completed 
because the implementation of the logical FRU device is ina 
state where the FRU information is temporarily unavailable. 
This could be due to a condition such as a loss of arbitration 
if the FRU is implemented as a device on a shared bus. 


Software can elect to retry the operation after at least 30 
milliseconds if this code is returned. Note that it is highly 
recommended that management controllers incorporate built- 
in retry mechanisms. Generic IPMI software cannot be relied 
upon to take advantage of this completion code. 


Count returned --- count is ‘1’ based 


:2+N | Requested data 


34.3 Write FRU Data Command 


The command writes the specified byte or word to the FRU Inventory Info area. This is a ‘low level’ direct 
interface to a non-volatile storage area. This means that the interface does not interpret or check any semantics or 
formatting for the data being written. The offset used in this command is a ‘logical’ offset that may or may not 
correspond to the physical address used in device that provides the non-volatile storage. For example, FRU 
information could be kept in FLASH at physical address 1234h, however offset 0000h would still be used with 
this command to access the start of the FRU information. IPMI FRU device data (devices that are formatted per 
[FRU]) as well as processor and DIMM FRU data always starts from offset OOOOh unless otherwise noted. 
Updating the FRU Inventory Data is presumed to be a system level, privileged operation. There is no requirement 
for devices implementing this command to provide mechanisms for rolling back the FRU Inventory Area in the 
case of incomplete or incorrect writes. 
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Table 34-, Write FRU Data Command 
byte data field 


Request Data 


Response Data Completion code. Generic, plus following command specific: 
80h = write-protected offset. Cannot complete write because one or 


more bytes of FRU data are to a write-protected offset in the 
FRU device. Note that an implementation may have allowed 
a ‘partial write’ of the data to occur. 

81h = FRU device busy. Refer to the preceding table for the Read 
FRU Command for the description of this completion code. 


Count written --- count is ‘1’ based 
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35. Sensor Device Commands 


The following table summarizes the commands that apply to a logical Sensor Device. Refer to Appendix G - 
Command Assignments for the specification of the Network Function and Command (CMD) values and privilege 
levels for these commands. 


Table 35-, Sensor Device Commands 


[Command TY Section [om] 
"Cod Rest 2 [0 
[Manufacturing Test Mode Or 205 [0 | 
Tese pp] 
[Device Space Commands Il 
Get Device SDR no == — | æ: [0] 
[SetSensorHysteresis Is [0 | 
[Get Sensor Hysteresis— | 7 [0 | 
[Set Sensor Threshold — 358 | 0 | 
[Set Sensor Event Dream | 0 | 
[Get Sensor Event Staus — REES |o 
SetSensorTpe == 358 |o 
[Set Sensor Reading and Event Status | sm | 0 | 


1.- Mandatory t Event T Message Keess only 
2.- Mandatory for Non-linear Sensors 

3.- Mandatory for manual re-arm Sensors 

4 

5 


Notes: 


Mandatory if corresponding ‘Set’ command is implemented. 
Mandatory per information returned in Get Device SDR Info 


451 


Intelligent Platform Management Interface Specification 


35.1 Static and Dynamic Sensor Devices 


Static Sensor Devices are defined as sensors that have their Sensor Data Records added to the SDR Repository 
when the device is configured into the system. This is normally done either as part of the manufacturing of the 
system, or via a separate utility when they are added to or deleted from the system configuration. 


Dynamic Sensor Devices rely on being discovered by responding to a Broadcast Get Device ID formatted to their 
slave address. (The IPMB format of this message is identical to that for a Get Device ID Request message that has 
the entire message prefixed with the DC broadcast slave address. [00h]) Once discovered, dynamic sensor devices 
can be queried for their sensor population via the Get Device SDR Info command. 


35.2 Get Device SDR Info Command 


This command returns general information about the collection of sensors in a Dynamic Sensor Device. 


Note: If the command is issued with no parameter for the request, the Device Sensor information is LUN based. 
That is, it is returned individually for each LUN. E.g.. a device could implement four sensors under one LUN, and 
twelve under another. The SDR Info does not return the aggregate of the sensor information. Rather, separate ‘Get 
Device SDR Info’ commands need to be issued to each LUN. The ‘Device LUNs’ field is provided in the 
response to support this. 


Software should assume an allocation unit size of 16-bytes for device SDRs. 


Table 35-, Get Device SDR Info Command 


Request Data Operation (optional) 
[7:1]- reserved 
[0] - 1b = Get SDR count. This returns the total number of SDRs in the 
device. 
Ob = Get Sensor count. This returns the number of sensors 
implemented on LUN this command was addressed to. 


Response Data = Completion Code 


For Operation = “Get Sensor Count” (or if byte 1 not present in request): 
Number of sensors in device for LUN this command was addressed to. 
For Operation = “Get SDR Count”: 
Total Number of SDRs in the device. 


Flags: 


Dynamic population 
[7] - Ob = static sensor population. The number of sensors handled by this 


device is fixed, and a query shall return records for all sensors. 
1b = dynamic sensor population. This device may have its sensor 

population vary during ‘run time’ (defined as any time other that 
when an install operation is in progress). 

Reserved 

[6:4] - reserved 

Device LUNs 

[3] - 1b =LUN 3 has sensors 

[2] - 1b = LUN 2 has sensors 

[1] - 1b =LUN 1 has sensors 

[0] - 1b = LUN 0 has sensors 

Sensor Population Change Indicator. LS byte first. 

Four byte timestamp, or counter. Updated or incremented each time the 

sensor population changes. This field is not provided if the flags indicate a 

static sensor population. 
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35.3 Get Device SDR Command 


The ‘Get Device SDR’ command allows SDR information for sensors for a Sensor Device (typically implemented 
in a Satellite management controller) to be returned. The Get Device SDR Command can return any type of SDR, 
not just Types O1h and 02h. This is an optional command for Static Sensor Devices, and mandatory for Dynamic 
Sensor Devices. The format and action of this command is similar to that for the "Get SDR’ command for SDR 
Repository Devices. 


A Sensor Device shall always utilize the same sensor number for a particular sensor. This is mandatory to keep 
System Event Log information consistent. 


Sensor Devices that support the ‘Get Device SDR’ command return SDR Records that match the SDR Repository 
formats. See section 0, 
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Sensor Data Record Formats. 


The ‘Get Device SDR’ command includes a Reservation ID that is used to notify the Requester that a record may 
have changed during the process of a multi-part read. See 33.11,Reserve SDR Repository, for more information on 
the function and use of the Reservation ID field. 


Table 35-, Get Device SDR Command 
Request Data Reservation ID. LS Byte. Only required for partial reads with a non-zero 
‘Offset into record’ field. Use 0000h for reservation ID otherwise. 
| 6 [Bytes to read. FFh means read entire record, SSS O 
Completion Code. Generic, plus following command specific: 
80h = record changed. This status is returned if any of the record contents 
| 2 | 


Response Data 


have been altered since the last time the Requester issued the request 
with 00h for the ‘Offset into SDR’ field. 


2 Record ID for next record, LS Byte 
Record ID for next record, MS Byte 
Requested bytes from record 


35.4 Reserve Device SDR Repository Command 


This command is used to obtain a Reservation ID. The Reservation ID is part of a mechanism that is used to 
notify the Requester that a record may have changed during the process of a multi-part read. See 33.11, Reserve 
SDR Repository, for more information on the function and use of Reservation IDs. 


Table 35-, Reserve Device SDR Repository 
byte data field 


Request Data | - | ooo U üO 
Response Data Completion Code 


Reservation ID, LS Byte 0000h reserved. 
Reservation ID, MS Byte 
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35.5 Get Sensor Reading Factors Command 


This command returns the Sensor Reading Factors fields for the specified reading value on the specified sensor. It 
is used for retrieving the conversion factors for non-linear sensors that do not fit one of the generic linearization 
formulas. See Non-Linear Sensors section. 


This command is provided for ‘analog’ sensor devices that are capable of holding a table of factors for 
linearization, but are incapable of performing the linearization calculations itself. Sensors that produce linear 
readings, but have non-linear accuracy or resolution over their range can also use this command. 


Note: the Response Data is based on the Version and Type of sensor record for the sensor. Only Type O1h record 
information is presently defined. 


Table 35-, Get Sensor Reading Factors Command 
Request Data sensor number (FFh = reserved) 


| 2 [reading byte 
Response Data = Completion Code 


Next reading. This field indicates the next reading for which a different set of 
sensor reading factors is defined. If the reading byte passed in the request 
does not match exactly to a table entry, the nearest entry will be returned, and 
this field will hold the reading byte value for which an exact table match would 
have been obtained. Once the ‘exact’ table byte has been obtained, this field 
will be returned with a value such that, if the returned value is used as the 
reading byte for the next request, the process can be repeated to cycle 
through all the Sensor Reading Factors in the device’s internal table. This 
process shall ‘wrap around’ such a complete list of the table values can be 
obtained starting with any reading byte value. 


Babies a an 


[7:6] - M: MS 2 bits 
EA Tolerance in +/- 7 raw counts 


| 5 [T:0]-B:LS8bts ` OE 0] - B: | [7:0] - B: LS 8 bits ` OSE 8 bits 

[7:6] - B: MS 2 bits 

Unsigned, 10-bit Basic Sensor Accuracy in 1/100 percent scaled up by 
unsigned Accuracy exponent. 

[5:0] - Accuracy: LS 6 bits 

[7:4] - Accuracy: MS 4 bits 

[3:2] - Accuracy exp: 2 bits, unsigned 

[1:0] - reserved: 2 bits, returned as 00b 


[7:4] - R (result) exponent 4 bits, signed 
[3:0] - B exponent 4 bits, signed 


35.6 Set Sensor Hysteresis Command 


This command provides a mechanism for setting the hysteresis values associated with the thresholds of a sensor 
that has threshold based event generation. Hysteresis setting applies to all thresholds for the sensor. The positive 
hysteresis value is used for positive-going thresholds, while the negative going threshold hysteresis value is used 
for negative-going thresholds. See section 35.13.2, Hysteresis and Event Status and section 35.13.3, High-going 
versus Low-going Threshold Events. 
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Table 35-, Set Sensor Hysteresis 
byte data field 
Request Data | 1 | sensor number (FFh = reserved) 


= reserved for future ‘hysteresis mask’ definition. Write as ‘FFh’ 


Positive-going Threshold Hysteresis Value. Set to 00h if sensor does not 
support positive-going threshold hysteresis. This value is subtracted from 
positive going thresholds to determine the point where the asserted status for 
that threshold will clear. See section 35. 13.2, Hysteresis and Event Status and 
section 35. 13.3, High-going versus Low-going Threshold Events. 
Negative-going Threshold Hysteresis Value. This value is added to negative 
going thresholds to determine the point where the asserted status for that 
threshold will clear. Set to 00h if sensor does not support negative-going 
threshold hysteresis. 


Response Data Completion Code 


35.7 Get Sensor Hysteresis Command 


This command retrieves the present hysteresis values for the specified sensor. If the sensor hysteresis values are 
‘fixed’, then the hysteresis values can be obtained from the SDR for the sensor. 


Table 35-, Get Sensor Hysteresis 
byte data field 
Request Data sensor number (FFh = reserved) 


Response Data 


35.8 Set Sensor Thresholds Command 


This command is used to set the specified threshold for the given sensor. Note that the application issuing this 
command is responsible for ensuring that thresholds for a sensor are set in the proper order (e.g. that the upper 
critical threshold is set higher than the upper non-critical threshold). 


Table 35-, Set Sensor Thresholds 
byte data field 
Request Data sensor number (FFh = reserved) 


7:6] - reserved. Write as OOb. 
]- 1b = set upper non-recoverable threshold 
]- 1b = set upper critical threshold 
]- 1b = set upper non-critical threshold 
]- 1b = set lower non-recoverable threshold 
1]- 1b = set lower critical threshold 
[0]- 1b= set lower non-critical threshold 


[ 
[5 
[4 
[3 
[2 
[ 


[3 lower non-critical threshold, ___1Ignoredbiderbyie2-o | 
[4 flower critical threshold. ___lgnoredif bit ofbyie2=0 | 
[6 [upper non-rtical tveshold. _____lanoredif bit 3ofbyie2= 0 | 
[8 [upper non-recoverable threshold value _Ignoredif it ofbyie2—0 | 
Response Data 
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35.9 Get Sensor Thresholds Command 


This command retrieves the threshold for the given sensor. 


Table 35-, Get Sensor Thresholds 
byte data field 


Request Data sensor number (FFh = reserved) 
Response Data Completion Code 
2 


[7:6] - reserved. Return as 00b. 
Readable thresholds: This bit mask indicates which thresholds are readable. 
[5]- 1b = upper non-recoverable threshold 
[4]- 1b = upper critical threshold 
[3]- 1b= upper non-critical threshold 
[2]- 1b= lower non-recoverable threshold 
[1]- 1b = lower critical threshold 
[0]- 1b = lower non-critical threshold 
| 6- [upper non-critical threshold (ff present, ignore on read otherwise) | 


upper critical (if present, ignore on read otherwise) 


upper non-recoverable (if present, ignore on read otherwise) 
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35.10 Set Sensor Event Enable Command 


This command provides the ability to disable or enable Event Message Generation for individual sensor events. 
The command is also used to enable or disable sensors in their entirety using the disable scanning bit. 


A typical sensor will come up with Event Messages (EvM) enabled for all thresholds/states. Sensors are not 
required to have individual or per-event Event Message enables. The type of enable/disable support that a sensor 
provides can be obtained from the Sensor Data Record for the sensor. 


Note that internal event flags and scanning will continue even though Event Message generation is disabled, 
unless sensor scanning is disabled. 


Table 35-, Set Sensor Event Enable 
byte data field 


Request Data sensor number (FFh = reserved) 
[7]- Ob = disable all Event Messages from this sensor (optional) [does not 
impact individual enable/disable status] 
[6]- Ob = disable scanning on this sensor (optional) 
[5:4] - OOb = do not change individual enables 
01b = enable selected event messages 
10b = disable selected event messages 
11b= reserved 
[3:0] - reserved 


For sensors with threshold based events: 

[7] - 1b = select assertion event for upper non-critical going high 

1b = select assertion event for upper non-critical going low 

1b = select assertion event for lower non-recoverable going high 
1b = select assertion event for lower non-recoverable going low 
1b = select assertion event for lower critical going high 

1b = select assertion event for lower critical going low 

1b = select assertion event for lower non-critical going high 

1b = select assertion event for lower non-critical going low 


For sensors with discrete events: 

[7] - 1b = select assertion event for state bit 7 

1b = select assertion event for state bit 6 

1b = select assertion event for state bit 5 

1b = select assertion event for state bit 4 

1b = select assertion event for state bit 3 

1b = select assertion event for state bit 2 

[ 1b = select assertion event for state bit 1 

[0] - 1b = select assertion event for state bit 0 

For sensors with threshold based events: 

[7:4] - reserved. Write as 0000b. 

1b = select assertion event for upper non-recoverable going high 
1b = select assertion event for upper non-recoverable going low 
1b = select assertion event for upper critical going high 

1b = select assertion event for upper critical going low 


For sensors with discrete events: 

[00h otherwise] 

reserved. Write as Ob. 

1b = select assertion event for state bit 14 
1b = select assertion event for state bit 13 
1b = select assertion event for state bit 12 
1b = select assertion event for state bit 11 
1b = select assertion event for state bit 10 
1b = select assertion event for state bit 9 
1b = select assertion event for state bit 8 
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For sensors with threshold based events: 

1b = select deassertion event for upper non-critical going high 

1b = select deassertion event for upper non-critical going low 

1b = select deassertion event for lower non-recoverable going high 
1b = select deassertion event for lower non-recoverable going low 
1b = select deassertion event for lower critical going high 

1b = select deassertion event for lower critical going low 

1b = select deassertion event for lower non-critical going high 

1b = select deassertion event for lower non-critical going low 


For sensors with discrete events: 

(00h otherwise) 

1b = select deassertion event for state bit 7 

1b = select deassertion event for state bit 6 

1b = select deassertion event for state bit 5 

1b = select deassertion event for state bit 4 

1b = select deassertion event for state bit 3 

1b = select deassertion event for state bit 2 

1b = select deassertion event for state bit 1 

1b = select deassertion event for state bit 0 

For sensors with threshold based events: 

[7:4] - reserved. Write as 0000b. 

1b = select deassertion event for upper non-recoverable going high 
1b = select deassertion event for upper non-recoverable going low 
1b = select deassertion event for upper critical going high 

1b = select deassertion event for upper critical going low 


For sensors with discrete events: 

(00h otherwise) 

reserved. Write as Ob. 

1b = select deassertion event for state bit 14 
1b = select deassertion event for state bit 13 
1b = select deassertion event for state bit 12 
1b = select deassertion event for state bit 11 
1b = select deassertion event for state bit 10 
1b = select deassertion event for state bit 9 
ibs select deassertion event for state bit 8 


Devices must accept this command with a variable number (2 to 6) of request data 
bytes. (In particular, bytes 3 to 6 do not need to be transferred if disabling all Event 
Messages from the sensor.) This requirement is to allow a reduction in the number 
of data bytes that must be transferred during the sensor initialization (init agent) 
process. The receiver shall treat data bytes that are not explicitly transmitted as if 
they were written as “OOh'. 
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35.11 Get Sensor Event Enable Command 


This command returns the enabled/disabled state for Event Message Generation from the selected sensor. The 
command also returns the enabled/disabled state for scanning on the sensor. 


A typical sensor will come up with Event Messages (EvM) enabled for all thresholds. Sensors are not required to 
have individual or per-event Event Message enables. The type of enable/disable support that a sensor provides can 
be obtained from the Sensor Data Record for the sensor. 


Table 35-, Get Sensor Event Enable 
byte data field 


| 1 | sensor number (EEN = reserved) 


Ze Completion Code 


[7]- Ob = All Event Messages disabled from this sensor 

[6]- Ob = Sensor scanning disabled 

[5:0] - reserved. Ignore on read. 

For sensors with threshold based events: 

[7]- 1b = assertion event for upper non-critical going high enabled 

1b = assertion event for upper non-critical going low enabled 

1b = assertion event for lower non-recoverable going high enabled 
1b = assertion event for lower non-recoverable going low enabled 
1b = assertion event for lower critical going high enabled 

1b = assertion event for lower critical going low enabled 

1b = assertion event for lower non-critical going high enabled 

1b = assertion event for lower non-critical going low enabled 


Request Data 
Response Data 


For sensors with discrete events: 
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[7] - 
[6] - 
[5] - 
[4] - 
[3] - 
[2] - 
[1] - 
[0] - 


1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
For sensors with threshold based events: 


for state bit 7 enabled 
for state bit 6 enabled 
for state bit 5 enabled 
for state bit 4 enabled 
for state bit 3 enabled 
for state bit 2 enabled 
for state bit 1 enabled 
for state bit 0 enabled 


For sensors with discrete events: 


[7:4] - reserved. Write as 0000b. 


[3] - 
[2] - 
[1] - 
[0] - 


1b = assertion event for upper non-recoverable going high enabled 
1b = assertion event for upper non-recoverable going low enabled 
1b = assertion event for upper critical going high enabled 

1b = assertion event for upper critical going low enabled 


(00h otherwise) 


[7] - 
[6] - 
[5] - 
[4] - 
[3] - 
[2] - 
[1] - 
[0] - 


reserved. 


1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 
1b = assertion event msg. 


for state bit 14 enabled 
for state bit 13 enabled 
for state bit 12 enabled 
for state bit 11 enabled 
for state bit 10 enabled 
for state bit 9 enabled 

for state bit 8 enabled 


For sensors with threshold based events: 
[7] - 


1b = deassertion event for upper non-critical going high enabled 

1b = deassertion event for upper non-critical going low enabled 

1b = deassertion event for lower non-recoverable going high enabled 
1b = deassertion event for lower non-recoverable going low enabled 
1b = deassertion event for lower critical going high enabled 

1b = deassertion event for lower critical going low enabled 

1b = deassertion event for lower non-critical going high enabled 

1b = deassertion event for lower non-critical going low enabled 
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For sensors with discrete events: 


[7] - 
[6] - 
[5] - 
[4] - 
[3] - 
[2] - 
[1] - 
[0] - 


1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
For sensors with threshold based events: 


for state bit 7 enabled 
for state bit 6 enabled 
for state bit 5 enabled 
for state bit 4 enabled 
for state bit 3 enabled 
for state bit 2 enabled 
for state bit 1 enabled 
for state bit 0 enabled 


[7:4] - reserved. Write as 0000b. 


[3]- 1b = deassertion event for upper non-recoverable going high enabled 
[2]- 1b = deassertion event for upper non-recoverable going low enabled 


[1]- 1b = deassertion event for upper critical going high enabled 
[0] - 1b = deassertion event for upper critical going low enabled 


For sensors with discrete events: 
(00h otherwise) 
[7]- reserved. 


[6] - 
[5] - 
[4] - 
[3] - 
[2] - 
[1] - 
[0] - 


1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 
1b = deassertion event msg. 


for state bit 14 enabled 
for state bit 13 enabled 
for state bit 12 enabled 
for state bit 11 enabled 
for state bit 10 enabled 
for state bit 9 enabled 

for state bit 8 enabled 


= Devices must accept a variable number of response data bytes (2 to 6). (In 
particular, bytes 3 to 6 do not need to be transferred if byte 2 indicates that all Event 
Messages have been disabled.) This requirement is to allow a reduction in the 
number of data bytes that must be transferred. It is recommended that 
implementations only return the number of data bytes required to satisfy the 
command. 


35.12 Re-arm Sensor Events Command 


This command is provided to enable software to re-arm thresholds on sensors that require ‘manual’ re-arming. It 
is also used to enable software to cause sensors (both manual and auto re-arm sensors) to regenerate events 
(update their event status and, if enabled, generate event messages) according to what event condition(s) currently 
exist (is presently in effect) when the re-arm command is executed. Thus, the re-arm is actually a request for the 
event status for a sensor to be rechecked and updated, and if enabled, generate event messages based on that event 
status. 


A reading/state unavailable (formerly “initial update in progress”) bit is provided with the Get Sensor Reading 
and Get Sensor Event Status commands to help software avoid getting incorrect event status due to a re-arm. For 
example, suppose a controller only scans for an event condition once every four seconds. Software that accessed 
the event status using the Get Sensor Reading command could see the wrong status for up to four seconds before 
the event status would be correctly updated. A controller that has slow updates must implement the initial update 
in progress bit, and should not generate event messages until the update has completed. Software should ignore 
the Event Status bits while the reading/state unavailable bit is set. 
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Table 35-, Re-arm Sensor Events 
byte data field 


Request Data sensor number (FFh = reserved) 

[7] - Ob = re-arm all event status from this sensor. If 0, following parameter 
bytes are ignored, but should still be written as 0, if sent. 

[6:0] - reserved. Write as 000 0000b. 

For sensors with threshold based events: 

[7] - 1b = re-arm assertion event for upper non-critical going high 

[6] - 1b = re-arm assertion event for upper non-critical going low 

[5] - 1b = re-arm assertion event for lower non-recoverable going high 
[4] - 1b = re-arm assertion event for lower non-recoverable going low 
[3] - 1b = re-arm assertion event for lower critical going high 

[2] - 1b = re-arm assertion event for lower critical going low 

[1] - 1b = re-arm assertion event for lower non-critical going high 

[0] - 1b = re-arm assertion event for lower non-critical going low 


For sensors with discrete events: 

[7] - 1b = re-arm assertion event for state bit 7 

[6] - 1b = re-arm assertion event for state bit 6 

[5] - 1b = re-arm assertion event for state bit 5 

[4] - 1b = re-arm assertion event for state bit 4 

[3] - 1b = re-arm assertion event for state bit 3 

[2] - 1b = re-arm assertion event for state bit 2 

1b = re-arm assertion event for state bit 1 

1b = re-arm assertion event for state bit 0 

For sensors with threshold based events: 

reserved. Write as 0000b. 

1b = re-arm assertion event for upper non-recoverable going high 
1b = re-arm assertion event for upper non-recoverable going low 
1b = re-arm assertion event for upper critical going high 

1b = re-arm assertion event for upper critical going low 


For sensors with discrete events: 

(00h otherwise) 

reserved. Ignore on read. 

1b = re-arm assertion event for state bit 14 

1b = re-arm assertion event for state bit 13 

1b = re-arm assertion event for state bit 12 

1b = re-arm assertion event for state bit 11 

1b = re-arm assertion event for state bit 10 

1b = re-arm assertion event for state bit 9 

1b = re-arm assertion event for state bit 8 

For sensors with threshold based events: 

[7] - 1b = re-arm deassertion event for upper non-critical going high 

[6] - 1b = re-arm deassertion event for upper non-critical going low 

[5] - 1b = re-arm deassertion event for lower non-recoverable going high 
[4] - 1b = re-arm deassertion event for lower non-recoverable going low 
[3] - 1b = re-arm deassertion event for lower critical going high 

[2] - 1b = re-arm deassertion event for lower critical going low 

[1] - 1b = re-arm deassertion event for lower non-critical going high 

[0] - 1b = re-arm deassertion event for lower non-critical going low 


For sensors with discrete events: 

(00h otherwise) 

1b = re-arm deassertion event for state bit 7 
1b = re-arm deassertion event for state bit 6 
1b = re-arm deassertion event for state bit 5 
1b = re-arm deassertion event for state bit 4 
1b = re-arm deassertion event for state bit 3 
1b = re-arm deassertion event for state bit 2 
1b = re-arm deassertion event for state bit 1 
1b = re-arm deassertion event for state bit 0 
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For sensors with threshold based events: 
reserved. Write as 0000b. 
1b = re-arm deassertion event for upper non-recoverable going high 
1b = re-arm deassertion event for upper non-recoverable going low 
1b = re-arm deassertion event for upper critical going high 
1b = re-arm deassertion event for upper critical going low 


For sensors with discrete events: 

(00h otherwise) 

[7] - reserved. Ignore on read. 

1b = re-arm deassertion event for state bit 14 
1b = re-arm deassertion event for state bit 13 
1b = re-arm deassertion event for state bit 12 
1b = re-arm deassertion event for state bit 11 
1b = re-arm deassertion event for state bit 10 
1b = re-arm deassertion event for state bit 9 
1b = re-arm deassertion event for state bit 8 


Response Data Oi | EED Code 


* = Devices must accept a variable number of request data bytes (2 to 6). This requirement is to allow a 
reduction in the number of data bytes that must be transferred. The receiver shall treat data bytes that 
are not explicitly transmitted as if they were written as ‘00h’. 


35.13 Get Sensor Event Status Command 


The Get Sensor Event Status command is provided to support systems where sensor polling is used in addition to, 
or instead of, Event Messages for event detection. The Get Sensor Event Status is also the only way to get the 
‘latched’ status for sensors that require manual re-arming of their event detection mechanism. 


A device that implements a sensor must only generate a single Event Message for a given sensor event. (Retries 
may cause this message to be sent multiple times - but it is still the same message from an event handling point- 
of-view). 


In order to track the fact that the event message has been sent, an implementation will typically implement an 
internal flag to indicate that the event condition has been met and the event generated. An ‘auto- re-arm’ sensor 
will clear its internal flag when the event condition goes away. A manual re-arm sensor requires a Re-arm Sensor 
Events command to clear the flag in order for event generation to be re-enabled for the event. The Get Sensor 
Event Status commands may be considered as returning the state of these internal flags. 


Since the ‘Event Status’ for a manual re-arm sensor stays until manual cleared, the state is sometime referred to as 
the ‘Event History’ or just ‘History’ for the sensor. 


The event status gets updated when the controller detects a state change or transition between the present state 
and the previous state (conditioned by hysteresis as appropriate). The exception to this is when a sensor is re- 
armed by a Re-arm Sensor or Set Event Receiver command. In this case, the event status gets updated after the 
controller gets its first reading for the sensor. 


35.13.1 Response According to Sensor Type 


The response to the Get Sensor Event Status command is dependent on the type of event generation for the 
sensor (threshold based or discrete) and whether the sensor is ‘manual re-arm’ or ‘auto- re-arm’. 


If the sensor is ‘manual re-arm’ then the command returns the latched event status for the sensor. This is 
essentially those ‘flag bits’ that indicate that the event had occurred and, if enabled, an event message was 
generated. A manual re-arm sensor that supports both assertion and deassertion events can have both assertion 
and deassertion event status set for a state simultaneously. 


If the sensor is ‘auto- re-arm’ then the command returns unlatched present event status for the sensor. The event 
status for auto- re-arm sensors can be derived from the present status information returned in a Get Sensor 
Reading command, if the hysteresis values are known. For this reason, the Get Sensor Event Status command is 
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typically not implemented for auto- re-arm sensors. Instead, if system management software needs to determine 
event status, it derives it from the Get Sensor Reading and hysteresis settings. 


The format of the Get Sensor Event Status response is dependent on whether the sensor was threshold based or 
discrete. 


Table 35-, Get Sensor Event Status Response Overview 


Status Returned 


Threshold based Present threshold comparison event status. This is redundant to the 
threshold comparison status returned with the ‘Get Sensor Reading’ 
command if the sensor has no hysteresis. Otherwise, software can 
derive the event status from the Get Sensor Reading command if it 
knows the hysteresis value. 


No Latched threshold comparison status. Since manual re-arm status is 

‘sticky’, the status may be different than the comparison status returned 
with the ‘Get Sensor Reading’ command. 

Discrete Yes Present event status represented by a bit mask indicating the event 
conditions that are presently active on the sensor. Note: this is 
redundant to the status returned with the ‘Get Sensor Reading’ 
command if there is no hysteresis associated with the sensor. 

No Latched event status represented by a bit mask indicating the event 
conditions that have been detected on the sensor. Since manual re-arm 


status is ‘sticky’, the status may be different than the comparison status 
returned with the ‘Get Sensor Reading’ command. 


35.13.2 Hysteresis and Event Status 


For threshold-based sensors the event status reflects whether the sensor is armed (ready to generate another 
event) or not. This means that there is a difference between the event status, returned by this command, and the 
comparison status returned by the Get Sensor Reading command. For example, suppose a sensor has an upper 
non-recoverable threshold with a threshold value of 98h and a positive-going threshold hysteresis value of 2. 
That sensor’s event status (byte 3, bit 5, below) would get set when the reading hit 98h, but would not clear 
until the reading hit 95h. (a 0 hysteresis would yield a re-arm point of 97h, therefore a positive-going hysteresis 
of 2 corresponds to a re-arm point of 95h). 


A sensor can only return a ‘1’ for the assertion or deassertion events that it supports. If a sensor does not support 
particular assertion or deassertion event states it must always return a ‘0’ for the bits associated with those 
states. For example, suppose a sensor supports assertion events for discrete state 0, but does not support 
deassertion events. The sensor will set the state 0 assertion event status to 1 when the event becomes asserted 
and to 0 when the event condition clears, but the state 0 deassertion event status bit will always be 0. This 
operation is specified so that a sensor does not return an ‘event occurred’ status for states that can not generate 
an Event Message. 


35.13.3 High-going versus Low-going Threshold Events 
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The differences between high-going and low-going threshold events are in what direction the reading needs to 
be going for an event to occur, in where deassertion events occur, and in how hysteresis affects where 
deassertion events occur. Figure 29-1, High-Going and Low-Going Event Assertion/Deassertion Points, 
illustrates these differences. 


A high-going threshold has its assertion events become set when the reading is 2 the threshold, while for a low- 
going event the assertion event becomes set when the reading is < the threshold. Even more difference is seen 
with where the de-assertion events occur. A high-going threshold must have the reading drop to a value that is 
positive_hysteresis+1 counts below the threshold value in order for the deassertion event to occur (and for the 
assertion event status to clear). A low-going threshold must have the reading rise to negative_hysteresis+1 
counts above the threshold to become deasserted. 
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Note that a zero hysteresis value still leads to a difference between where the deassertion events occur. An event 
can’t be in the asserted and deasserted states simultaneously. Thus, for zero hysteresis a high-going threshold 
event becomes asserted when the reading is > the threshold, and becomes deasserted when the reading goes < 
the threshold minus one. A low-going threshold event becomes asserted when the reading goes < the threshold, 
and becomes deasserted when the reading goes = the threshold plus one. 


A system implementation will typically only use either high-going or low-going events for a given threshold, 
but not both simultaneously. 


Figure 35-, 
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AGL (40) DGL(43) 


AGH = Assertion Going-High 
DGH = Deassertion Going-High 
AGL = Assertion Going-Low 
DGL = Deassertion Going-Low 


reading 


35.13.4 Get Sensor Event Status Command Format 


The following table shows the format of the Get Sensor Event Status command. 


Request Data 
Response Data 


Table 35-, Get Sensor Event Status Command 
Sensor number (FFh = reserved) 


Completion Code 


Ob = All Event Messages disabled from this sensor 
Ob = Sensor scanning disabled 
1b = reading/state unavailable (formerly “initial update in progress”). This bit 
is set to indicate that a ‘re-arm’ or ‘Set Event Receiver’ command has been 
used to request an update of the sensor status, and that update has not 
occurred yet. Software should use this bit to avoid getting an incorrect status 
while the first sensor update is in progress. This bit is only required if it is 
possible for the controller to receive and process a ‘Get Sensor Reading’ or 
‘Get Sensor Event Status’ command for the sensor before the update has 
completed. This is most likely to be the case for sensors, such as fan RPM 
sensors, that may require seconds to accumulate the first reading after a re- 
arm. The bit is also used to indicate when a reading/state is unavailable 
because the management controller cannot obtain a valid reading or state 
for the monitored entity, typically because the entity is not present. See 
Section 16.4, Event Status, Event Conditions, and Present State and Section 
16.6, Re-arming for more information. 

[4:0] - reserved. Ignore on read. 
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For sensors with threshold based events: 
(High-going events are asserted when value first becomes > threshold. Low-going 


[7] - 


events are asserted when value first becomes < corresponding threshold.) 
1b = assertion event condition for upper non-critical going high occurred 

1b = assertion event condition for upper non-critical going low occurred 

1b = assertion event condition for lower non-recoverable going high occurred 
1b = assertion event condition for lower non-recoverable going low occurred 
1b = assertion event condition for lower critical going high occurred 

1b = assertion event condition for lower critical going low occurred 

1b = assertion event condition for lower non-critical going high occurred 

1b = assertion event condition for lower non-critical going low occurred 


For sensors with discrete events: 


1b = state 7 assertion event occurred 
1b = state 6 assertion event occurred 
1b = state 5 assertion event occurred 
1b = state 4 assertion event occurred 
1b = state 3 assertion event occurred 
1b = state 2 assertion event occurred 
1b = state 1 assertion event occurred 
1b = state 0 assertion event occurred 


For sensors with threshold based events: 


[3] - 


[2] - 
[1] - 
[0] - 


[7:4] - reserved. Write as 0000b. 


1b = assertion event condition for upper non-recoverable going high 
occurred 

1b = assertion event condition for upper non-recoverable going low occurred 
1b = assertion event condition for upper critical going high occurred 

1b = assertion event condition for upper critical going low occurred 


For sensors with discrete events: 


(00h otherwise) 


[7] - 
[6] - 
[5] - 
[4] - 
[3] - 
[2] - 
[1] - 
[0] - 


reserved. Ignore on read. 

1b = state 14 assertion event occurred 
1b = state 13 assertion event occurred 
1b = state 12 assertion event occurred 
1b = state 11 assertion event occurred 
1b = state 10 assertion event occurred 
1b = state 9 assertion event occurred 
1b = state 8 assertion event occurred 
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For sensors with threshold based events: 

(High-going events are deasserted when value goes less than the corresponding 
threshold minus the positive-going hysteresis value. Low-going events are 
deasserted when value goes greater than the corresponding threshold plus the 
negative-going hysteresis value.) 

[7]- 1b = deassertion event condition for upper non-critical going high occurred 
[6]- 1b = deassertion event condition for upper non-critical going low occurred 
[5]- 1b =deassertion event condition for lower non-recoverable going high 
occurred 

1b = deassertion event condition for lower non-recoverable going low 
occurred 

1b = deassertion event condition for lower critical going high occurred 

1b = deassertion event condition for lower critical going low occurred 

1b = deassertion event condition for lower non-critical going high occurred 
1b = deassertion event condition for lower non-critical going low occurred 


1b = state 7 deassertion event occurred 

1b = state 6 deassertion event occurred 

1b = state 5 deassertion event occurred 

1b = state 4 deassertion event occurred 

1b = state 3 deassertion event occurred 

1b = state 2 deassertion event occurred 

1b = state 1 deassertion event occurred 

1b = state 0 deassertion event occurred 

For sensors with threshold based events: 

[7:4] - reserved. Write as 0000b. 

[3]- 1b = deassertion event condition for upper non-recoverable going high 
occurred 

[2]- 1b = deassertion event condition for upper non-recoverable going low 
occurred 

[1]- 1b =deassertion event condition for upper critical going high occurred 
[0] - 1b =deassertion event condition for upper critical going low occurred 


For sensors with discrete events: 

(Oh otherwise) 

[7]- reserved. Ignore on read. 

[6]- 1b = state 14 deassertion event occurred 
[5]- 1b = state 13 deassertion event occurred 
[4]- 1b = state 12 deassertion event occurred 
[3]- 1b = state 11 deassertion event occurred 
[2]- 1b = state 10 deassertion event occurred 
[1]- 1b = state 9 deassertion event occurred 
[0] - 1b = state 8 deassertion event occurred 


* = Devices must accept a variable number of response data bytes (3 to 6). This 
requirement is to allow a reduction in the number of data bytes that must be transferred. It is 
recommended that implementations only return the number of data bytes required to satisfy 
the command. 


35.14 Get Sensor Reading Command 


This command returns the present reading for sensor. The sensor device may return a stored version of a 
periodically updated reading, or the sensor device may scan to obtain the reading after receiving the request. 


The meaning of the state bits returned by Discrete sensors is based on the Event/Reading Type code from the SDR 
for the sensor. This can also be obtained directly from the controller if the optional Get Sensor Type command is 
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supported for the sensor. Refer to Section 41.2, Event/Reading Type Code, for information on interpreting 
Event/Reading Type codes when used for present readings. 


Table 35-, Get Sensor Reading Command 
Request Data sensor number (FFh = reserved) 


Response Data Completion Code. 
2 S 


ensor reading 

Byte 1: byte of reading. lgnore on read if sensor does not return an numeric 

(analog) reading. 
= All Event Messages disabled from this sensor 

sensor scanning disabled 
reading/state unavailable (formerly “initial update in progress”). 
This bit is set to indicate that a ‘re-arm’ or ‘Set Event Receiver’ 
command has been used to request an update of the sensor 
status, and that update has not occurred yet. Software should 
use this bit to avoid getting an incorrect status while the first 
sensor update is in progress. This bit is only required if it is 
possible for the controller to receive and process a ‘Get Sensor 
Reading’ or ‘Get Sensor Event Status’ command for the sensor 
before the update has completed. This is most likely to be the 
case for sensors, such as fan RPM sensors, that may require 
seconds to accumulate the first reading after a re-arm. The bit 
is also used to indicate when a reading/state is unavailable 
because the management controller cannot obtain a valid 
reading or state for the monitored entity, typically because the 
entity is not present. See Section 16.4, Event Status, Event 
Conditions, and Present State and Section 16.6, Re-arming for 
more information. 

[4:0] - reserved. Ignore on read. 

For threshold-based sensors 

Present threshold comparison status 

[7:6] - reserved. Returned as 1b. Ignore on read. 


[5] - 1b = at or above (=) upper non-recoverable threshold 


[4] - 1b = at or above 
[3] - 1b = at or above 
[2] - 1b = at or below (<) lower non-recoverable threshold 
[1] - 1b = at or below (<) lower critical threshold 

[0] - 1b = at or below (<) lower non-critical threshold 


2) upper critical threshold 
2) upper non-critical threshold 


( 
( 


For discrete reading sensors 

[7] - 1b = state 7 asserted 

[6] - 1b = state 6 asserted 

[5] - 1b = state 5 asserted 

[4] - 1b = state 4 asserted 

[3] - 1b = state 3 asserted 

[2] - 1b = state 2 asserted 

[1] - 1b = state 1 asserted 

[0] - 1b = state 0 asserted 

For discrete reading sensors only. (Optional) 
(00h Otherwise) 

[7] - reserved. Returned as 1b. Ignore on read. 
[6] - 1b = state 14 asserted 

[5] - 1b = state 13 asserted 

[4] - 1b = state 12 asserted 

[3] - 1b = state 11 asserted 

[2] - 1b = state 10 asserted 

[1] - 1b = state 9 asserted 

[0] - 1b = state 8 asserted 
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35.15 Set Sensor Type Command 


This command is used to assign the Sensor Type and Event/Reading Type to a specified sensor. A management 
controller that implements sensors and generates events for those sensors must return the Sensor Type and 
Event/Reading Type in the Event Messages from those sensors. By allowing those values to be assigned, it is 
possible to create a ‘generic’ management controller with fixed firmware that is field configured with sensor type, 
reading, and event type information for the particular application. 


For example, a controller could provide a set of unassigned ‘digital’ discrete sensors. The Set Sensor Type 
command could allow one of these sensors to be set as a ‘Processor’ sensor that returns ‘Inserted/Removed’ 
status, and generates an event on ‘Removed’. Another sensor could be assigned to be a Physical Security (Chassis 
Intrusion) sensor the returns 


The same approach could be used to assign monitoring functions to a controller that provides A/D inputs and an 
associated set of unassigned threshold-based analog sensors. One sensor could be assigned to be a voltage sensor, 
while another could be assigned to be a temperature sensor, etc. 


The Sensor Data Records include an ‘Init Sensor Type’ bit that indicates whether this information should be 
assigned to the controller as part of the Initialization Agent process. 


The controller can implement this command such that the assignment is volatile or non-volatile. A non-volatile 
assignment would allow the assignment to be retained across power cycles or system resets, at the cost of 
providing non-volatile storage for the controller. A controller that has a volatile assignment would rely on the 
Initialization Agent function to assign the sensor type. This trade-off with this approach is that there would be 
more times when the sensor was disabled and unassigned prior to the execution of the Initialization Agent 
process. 


Table 35-, Set Sensor Type Command 
Request Data io sensor number (FFh = reserved) 
= sensor type (per Table 42-, Sensor Type Codes) 


[7] - reserved 
[6:0] - Event/Reading type code (per Table 42-, Generic Event/ Reading 
Type Codes) 


Response Data ao | Completion Code. 


35.16 Get Sensor Type Command 


This command is used to retrieve the Sensor Type and Event/Reading Type for the specified sensor. This 
command is mandatory for sensors that respond to the Set Sensor Type command. 


Table 35-, Get Sensor Type 
Request Data sensor number (FFh = reserved) 


Response Data [1 | Completion Code. 


= sensor type (per Table 42-, Sensor Type Codes) 


[7]- reserved. 
[6:0] - Event/Reading type code (per Table 42-, Generic Event/Reading Type 
Codes) 


469 


Intelligent Platform Management Interface Specification 


35.17 Set Sensor Reading And Event Status Command 


This command enables software to set the present reading and event status for sensors that support this command. 
This can be used to create sensors where the data comes from software, such as a BIOS SMI handler, rather than 
being directly polled or accessed by BMC (or satellite management controller) hardware. The Type 01h and Type 
02h SDRs include an optional bit that allows those records to report that a sensor is settable. 


The command sets the event state and data values for the sensor directly into the management controller. The 
management controller simply takes the parameters that are given to it and generates events based on the event 
state settings. The management controller is not required to autonomously update the sensor event state based on 
reading values. There is also no requirement for the BMC to make sure the event state and reading are in synch 
with one another, though an implementation is allowed to reject ‘illegal’ combinations. 


For example, if a sensor is threshold-based, the implementation is not required to update threshold state based on 
the data value. Thus, software should always set the event state whenever it wants to cause events to be generated 
based on data that is set with this command. 


Since the management controller is not required to automatically update sensor event state, this means it is not 
required to automatically clear or rearm event state once a given event state has been set. Therefore, if software 
asserts an event state using this command, it will need to issue a separate command to explicitly deassert that state 
before another event can be generated. 
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Table 35-18, Set Sensor Reading and Event Status Command 


Request Data 


sensor number (FFh = reserved) 


Operation 
[7:6] - Event Data Bytes operation 
This field controls whether associated event data bytes are written or left 
unchanged for the given sensor. These event data bytes will be returned in 
any event message generated by the sensor. 
11b = reserved 
10b = Write given values to event data bytes, excluding bits [3:0] of 
Event Data 1. (If values trigger an event, BMC will automatically 
generate bits [3:0] based on the sensor reading and event 
status.) 
Write given values to event data bytes, including bits [3:0] of 
Event Data 1 (bits [3:0] written to Event Data 1 will override 
BMC generation of the event offset value on next event 
generated by the given sensor.) 
Don’t use Event Data bytes from this command. BMC will 
generate it’s own Event Data bytes based on its sensor 
implementation. 


[5:4] - Assertion bits operation 
This field controls whether the corresponding assertion event status bits in the 
given sensor get set cleared according to the assertion event status 
parameters in this command, or are left unchanged. If the parameter for the 
assertion bits is absent from this command, the corresponding assertion bits 
in the sensor (if any) will remain unchanged regardless of the selected 
operation. 
11b = A Ob in a given bit position in the given parameter causes 
corresponding bit position to be cleared. A 1b causes no change 
to the corresponding 
10b = A 1b in a given bit position causes corresponding bit position to 
be set to 1b. A 0b 
01b = write given value to assertion event status bytes 
00b = don’t change assertion event status bytes 


[3:2] - Deassertion bits operation 
This field controls whether the deassertion event status bits in the given 
sensor get set, cleared according to the deassertion event status parameters 
in this command, or are left unchanged. If the parameter for the deassertion 
bits is absent from this command, the corresponding assertion bits in the 
sensor (if any) will remain unchanged regardless of the selected operation. 
11b = A Ob in a given bit position in the given parameter causes 
corresponding bit position to be cleared. A 1b causes no change 
to the corresponding 
10b = A 1b in a given bit position causes corresponding bit position to 
be set to 1b. A 0b 
01b = write given value to assertion event status bytes 
00b = don’t change assertion event status bytes 


[1:0] - Sensor Reading operation 
This field controls whether the sensor reading byte is written or left unchanged 
according to the sensor 
10b, 11b = reserved 
01b = write given value to sensor reading byte 
00b = don’t change sensor reading byte 
Sensor Reading 
Byte 1: byte of reading. 
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For sensors with threshold based events: 
(High-going events are asserted when value first becomes > threshold. Low- 


[7] - 


[6] - 
[5] - 


[4] - 
[3] - 
[2] - 
[1] - 


[0] - 


going events are asserted when value first becomes < corresponding 
threshold.) 

1b = assertion event condition for upper non-critical going high 
occurred 

1b = assertion event condition for upper non-critical going low occurred 
1b = assertion event condition for lower non-recoverable going high 
occurred 

1b = assertion event condition for lower non-recoverable going low 
occurred 

1b = assertion event condition for lower critical going high occurred 

1b = assertion event condition for lower critical going low occurred 

1b = assertion event condition for lower non-critical going high 
occurred 

1b = assertion event condition for lower non-critical going low occurred 


For sensors with discrete events: 


pI- 
[6] - 
[5] - 
[4] - 
[3] - 
[2] - 
[1] - 
[0] - 


1b = state 7 assertion event occurred 
1b = state 6 assertion event occurred 
1b = state 5 assertion event occurred 
1b = state 4 assertion event occurred 
1b = state 3 assertion event occurred 
1b = state 2 assertion event occurred 
1b = state 1 assertion event occurred 
1b = state 0 assertion event occurred 


For sensors with threshold based events: 


[7:4] - reserved. Write as 0000b. 


[3] - 


[2] - 


UE 
[0] - 


1b = assertion event condition for upper non-recoverable going high 
occurred 

1b = assertion event condition for upper non-recoverable going low 
occurred 

1b = assertion event condition for upper critical going high occurred 
1b = assertion event condition for upper critical going low occurred 


For sensors with discrete events: 


(00h otherwise) 


[7] - 
[6] - 
[5] - 
[4] - 
[3] - 
[2] - 
[1] - 
[0] - 


reserved. Ignore on read. 

1b = state 14 assertion event occurred 
1b = state 13 assertion event occurred 
1b = state 12 assertion event occurred 
1b = state 11 assertion event occurred 
1b = state 10 assertion event occurred 
1b = state 9 assertion event occurred 
1b = state 8 assertion event occurred 
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For sensors with threshold based events: 

(High-going events are deasserted when value goes less than the 

corresponding threshold minus the positive-going hysteresis value. Low-going 

events are deasserted when value goes greater than the corresponding 

threshold plus the negative-going hysteresis value.) 

[7]- 1b = deassertion event condition for upper non-critical going high 
occurred 

[6]- 1b = deassertion event condition for upper non-critical going low 
occurred 

[5]- 1b = deassertion event condition for lower non-recoverable going high 
occurred 

[4]- 1b =deassertion event condition for lower non-recoverable going low 
occurred 

[3]- 1b =deassertion event condition for lower critical going high occurred 

[2]- 1b =deassertion event condition for lower critical going low occurred 

[1]- 1b =deassertion event condition for lower non-critical going high 
occurred 

[0]- 1b =deassertion event condition for lower non-critical going low 
occurred 


For sensors with discrete events: 

[7]- 1b = state 7 deassertion event occurred 

[6] - 1b = state 6 deassertion event occurred 

[5] - 1b = state 5 deassertion event occurred 

[4] - 1b = state 4 deassertion event occurred 

[3] - 1b = state 3 deassertion event occurred 

[2] - 1b = state 2 deassertion event occurred 

[1] - 1b = state 1 deassertion event occurred 

[0] - 1b = state 0 deassertion event occurred 

For sensors with threshold based events: 

[7:4] - reserved. Write as 0000b. 

[3] - 1b = deassertion event condition for upper non-recoverable going high 
occurred 

[2] - 1b = deassertion event condition for upper non-recoverable going low 
occurred 

[1]- 1b = deassertion event condition for upper critical going high occurred 

[0] - 1b = deassertion event condition for upper critical going low occurred 


For sensors with discrete events: 

(Oh otherwise) 

[7]- reserved. Ignore on read. 

[6]- 1b = state 14 deassertion event occurred 
[5] - 1b = state 13 deassertion event occurred 
[4] - 1b = state 12 deassertion event occurred 
[3]- 1b = state 11 deassertion event occurred 
[2]- 1b = state 10 deassertion event occurred 
[1]- 1b = state 9 deassertion event occurred 
[0] - _ 1b = state 8 deassertion event occurred 
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Event Data 1 (See Table 29 6, Event Request Message Event Data Field 
Contents). 


Note: bits 3:0 of Event Data 1 are the event offset. It is up to the party issuing 
this command to ensure that any values written to the event offset field 
are consistent with values written to the Reading and State fields. The 
Event Data Bytes operation field in byte 1 of this request can be used 


to select whether the BMC automatically generates the event offset 
bits or uses values passed in this byte. 


(9)* | Event Data 2 


(10)* | Event Data 3 
Completion Code. 


Generic plus the following command-specific completion codes: 


80h: Attempt to change reading or set or clear status bits that are not 
settable via this command 


Attempted to set Event Data Bytes, but setting Event Data Bytes is not 
supported for this sensor. 


Devices must accept a variable number of request data bytes (4 to 10). This requirement is to 
allow a reduction in the number of data bytes that must be transferred. 


Response Data 


81h: 
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35b. Command Forwarding Commands 


Command Forwarding is an optional capability that can be used to support add-in cards or auxiliary management 
controllers. This functionality enables the specified commands on a given interface to be forwarded from the BMC 
to the add-in instead of being processed directly by the BMC. The BMC accomplishes this by encapsulating the 
forwarded command within a Forwarded Command command that it then sends to the target controller on the add- 
in. Correspondingly, the controller on the add-in can uses the Forwarded Command to return forwarded command 
responses to the BMC. 


Only requests from the source to the target need to be forwarded. If the target (add-in) needs to deliver a request to a 
particular channel, it can use the Send Message command to do so. Bridging in the BMC will then handle the 
routing of the response back to the target. Thus, the Forwarded Command command is only used to forward request 
messages to the target. Correspondingly, the BMC does not itself accept Forwarded Command requests, just 
responses. 


This is similar in operation to the Send Message command. The general process for initializing and using Command 
Forwarding is: 


e The Set Forwarded Commands command is used to select which commands are to be forwarded from a 
given channel. In this section, channels that receive commands that are to be forwarded are referred to as 
sources for Command Forwarding. 


e The Enable Forwarded Commands command is used to configure which controller will receive the 
forwarded commands, and also to enable (activate) Command Forwarding. In this section, the controller 
that receives and processes forwarded commands is referred to as the target controller for Command 
Forwarding. 


e Subsequently, when the BMC receives a command over a channel, it checks to see if Command 
Forwarding is enabled for that channel, and whether the command is to be Forwarded. 


e Ifthe command is to be forwarded, the BMC encapsulates the IPMI common command fields (i.e. NetFn, 
LUN, CMD) in a Forwarded Command request message to the target controller. 


e When the BMC issues the Forwarded Command command, it temporarily records the sequence number 
that was used to send that command, along with information necessary to format and route the 
corresponding response data back to the source channel. 


e The target receives the Forwarded Command request, processes it, and returns a Forwarded Command 
response. This response contains the encapsulated IPMI message data the original, forwarded, request. The 
BMC uses the sequence number in this response to look up how to route and format the response data for 
the particular source channel. 


Table 35b-1, Command Forwarding Commands 
Section 
Command Defined 


Get Forwarded Commands 35b.1 


Set Forwarded Commands 35b.2 
Enable Forwarded Commands 35b.3 
Forwarded Command 35b.4 
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35b.1 Get Forwarded Commands Command 


This command enables software to determine which commands are presently enabled for command forwarding from 
a given channel on the BMC. 


Table 35b-2 Get Forwarded Commands Command 


Byte Data field 
Request Data 1 Source Channel Number (number for the channel that is the source 
of forwarded commands) 
2 [7:6] Operation 


OOb = return forwarded mask for commands 00h through 7Fh 
01b = return forwarded mask for commands 80h through FFh 
10b, 11b = reserved 


[5:0] NetFn 
3 [7:2] reserved 
[1:0] LUN 
Response Data 1 Completion code 
217 Forwarded Commands mask 


These sixteen bytes form a 128-bit bitfield where each bit 
indicates a particular command value under the given NetFn for 
which forwarding is enabled. 
For each bit in the bitfield: 
Ob = indicates the command is not forwarded 
1b = indicates the command is forwarded 
Depending on the value of the “Operation” parameter passed in the 
request: 
Byte 1, bit 0 corresponds to command 00h or command 80h 


Byte 16, bit 7 corresponds to command 7Fh or command FFh 
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35b.2 Set Forwarded Commands Command 


This command enables software to set which commands are presently enabled for command forwarding from a 


given channel on the BMC. 


Table 35b-3, Set Forwarded Commands Command 


Data field 


Source Channel Number (number for the channel that is the 
source of forwarded commands) 
All supported source channels are configured independently. 


[7:6] Operation 
00b = set forwarded command mask for commands 00h 
through 7Fh 
01b = set forwarded command mask for commands 80h 
through FFh 
10b = disable Command Forwarding from this channel 
11b = enable Command Forwarding form this channel 
[5:0] NetFn 


[7:2] reserved 
[1:0] LUN 


Byte 
Request Data 1 
= 
3 
4:19 
Response Data 1 


Forwarded Command mask 
These sixteen bytes forms a 128-bit bitfield where each bit 
indicates a particular command value under the given NetFn 
for which forwarding is enabled 
For each bit in the bitfield: 
Ob = indicates the command is not forwarded 
1b = indicates the command is forwarded 
Depending on the value of the “Operation” parameter passed in 
the request: 
Byte 1, bit 0 corresponds to command 00h or command 80h 


Byte 16, bit 7 corresponds to command 7Fh or command FFh 
Completion code 


35b.3 Enable Forwarded Commands Command 


This command allows enabling and disabling Command Forwarding, and also provides the ability to configure 
which interface (channel) the BMC sends forwarded commands to and receives forwarded command responses 


from. 


Note: a given BMC may not support Command Forwarding over all channels. The command returns which channels 
command forwarding can be targeted to. 


Table 35b-4, Enable Forwarded Commands Command 


Byte Data field 


Request Data 


1 [7:2] - reserved 
[1:0] - Operation: 
00b = get present configuration 


LUN 


01b = set target controller channel, slave address and 


10b = enable Command Forwarding from given channel 
11b = disable Command Forwarding from given channel 


2 Channel Number to be used for channel between BMC and 


target controller 
[3:0] - channel number. 
Oh-Bh = channel numbers 
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OCh-OFh = reserved 
3 Target Controller LUN 
[7:2] - reserved 
[1:0] - target controller LUN 
4 Target Controller Slave Address 
[7:1] - controller slave address 
[Ob] - reserved. Write as Ob. 
5 Forwarded command time-out, in 10’s of ms. 1-based. 30 
ms, min. Sets the minimum time the BMC will wait before 
timing out waiting for a response to a Forwarded Command 
command. 
00h-02h = reserved. 
O3h-FFh = timeout in 10's of ms. E.g. 03h = 30 ms. 

Response Data 1 Completion code 
2 Command Forwarding Status 
[7:2] - reserved 
[1:0] - command forwarding status 

11b = command forwarding disabled 

10b = command forwarding enabled 

all other = reserved 
3 Channel Number to used for channel between BMC and 
target controller. 
[3:0] - channel number. 

Oh-7h = channel numbers 
08h-OFh = reserved 

4 Target Controller LUN 
[7:2] - reserved 
[1:0] - target controller LUN 
5 Target Controller Slave Address 
[7:1] - controller slave address 
[Ob] - reserved. Write as Ob. 
6 Forwarded command time-out, in 10’s of ms. 1-based. 30 
ms, min. Sets the minimum time the BMC will wait before 
timing out waiting for a response to a Forwarded Command 
command. 
00h-02h = reserved. 
03h-FFh = timeout in 10's of ms. E.g. 03h = 30 ms. 
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1:8 


Source Channel Support 
bitfield indicating which channel numbers are available for 
use for Command Forwarding sources. 


The implementation must allow all supported source 
channels for command forwarding to be enabled and used 
for command forwarding simultaneously. 


byte 1: 

[7] - 1b = channel 7 supported for Command Forwarding 

[6] - 1b = channel 6 supported for Command Forwarding 

[5] - 1b = channel 5 supported for Command Forwarding 

[4] - 1b = channel 4 supported for Command Forwarding 

[3] - 1b = channel 3 supported for Command Forwarding 

[2] - 1b = channel 2 supported for Command Forwarding 

[1] - 1b = channel 1 supported for Command Forwarding 

[0] - 1b = channel 0 (primary IPMB) supported for Command 

Forwarding 


byte 2: 

[7] - 1b = channel Fh (system interface) supported for 
Command Forwarding. 

[6:4] - reserved 

[3] - 1b = channel Bh supported for Command Forwarding 

[2] - 1b = channel Ah supported for Command Forwarding 

[1] - 1b = channel 9 supported for Command Forwarding 

[0] - 1b = channel 8 supported for Command Forwarding 


9:10 


Target Channel Support 
bitfield indicating which channel numbers are available for 
selection as the target channel for forwarded commands. 


Note: 

e Only one channel at a time can be set as the target 
channel per this version of the specification. 

e Only channels of type IPMB or PCI-SMBus are 
supported as targets with this version of the 
specification. 

e OEM channel use is allowed, but the mechanism 
used for handling forwarded commands on an 
OEM channel is outside this specification. 


byte 1: 

[7] - 1b = channel 7 supported for Command Forwarding 

[6] - 1b = channel 6 supported for Command Forwarding 

[5] - 1b = channel 5 supported for Command Forwarding 

[4] - 1b = channel 4 supported for Command Forwarding 

[3] - 1b = channel 3 supported for Command Forwarding 

[2] - 1b = channel 2 supported for Command Forwarding 

[1] - 1b = channel 1 supported for Command Forwarding 

[0] - 1b = channel 0 (primary IPMB) supported for Command 

Forwarding 


byte 2: 

[7:4] - reserved 

[3] - 1b = channel Bh supported for Command Forwarding 
[2] - 1b = channel Ah supported for Command Forwarding 
[1] - 1b = channel 9 supported for Command Forwarding 
[0] - 1b = channel 8 supported for Command Forwarding 
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35b.4 Forwarded Command Command 


This command is used to encapsulate the forwarded command data between the add-in and the BMC. Below are 
examples of the format of this command used to forward a request to a target controller on IPMB. 


Note that for IPMB this encapsulation adds at least three bytes of overhead to forwarded requests, since there are 
two occurrences of NetFn/LUN and CMD bytes, plus a field for the source channel number. (If the request is from a 
session-based channel, two additional bytes of overhead are required.) For responses, there are three bytes of 
overhead because the completion code byte is also duplicated. Thus, to support this command, the BMC must 
include sufficient additionally buffering to accept this additional overhead for all interfaces that support using the 
Forwarded Command message to deliver a message to a given target. 


Example: Format of Forwarded Command request message used to carry a forwarded request from BMC 
to target controller (add-in) via IPMB: 


RsSA | NetFn/RsLun | Chk1 
(NetFn=even) 


RqSA_ | Seq/RqLUN CMD=Forwarded Command Channel number 


Encapsulated Request > NetFn/LUN | CMD | Data 
Chk2 


Example: Format of Forwarded Command response message from target controller (add-in) to BMC via 
IPMB: 


RaSA | NetFn/RqLun | Chk1 
(NetFn=odd) 
RsSA | Sea/RsLUN CMD=Forwarded Command 
Completion Code 
Encapsulated Response > NetFn/LUN | CMD | Completion Code | Data 
Chk2 


The BMC will time out and return an FFh or C3h (Timeout while processing command. Response unavailable.) 
error completion code to the requester if the target controller does not return a matching Forwarded Command 
response message within the timeout set by the Enable Forwarded Commands command. 


The Forwarded Command command is only sent out by the BMC as a request. It is not accepted as a request by the 
BMC itself. 


Table 35b-5, Forwarded Command Command 
Request Data 1 [7]- 1b = forwarded request is from a session-based 
channel 
[6:4] - reserved 
[3:0] - Channel number. 


EM [7:6] - reserved. 
[5:0] - User ID. Use 000000b for single-session channels. 
KIM [7:4] - User Maximum Privilege Levell?! 


[3:0] - User Operating Privilege Levell? (present privilege 
level User that originated request is operating at) 


4m] Session Handle. Use 00h for single-session channels. 
SN Forwarded Command Request Data 
Response Data 1 Completion Code 
Generic plus the following command-specific completion 
codes: 


80h: Target controller unavailable. 
The forwarded command failed because the target 
controller could not accept the request. (On SMBus or 
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PC/IPMB, this would be the case if the target controller 
were absent, or if it actively NAK’d the command). 


BMC shall return FFh or C3h (Timeout while processing 
command. Response Unavailable) completion code if the 
target controller does not return a matching Forwarded 
Command response message within the timeout set by the 
Enable Forwarded Commands command. 


2:M Forwarded Command Response Data 


. These fields present only if request is forwarded from a session-based 


channel. 


. Value is captured at time that the request is received and interpreted by the 


BMC. 
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36. Sensor Types and Data Conversion 


Sensors can be generally classified into two types, Linear/Linearizable Sensors and Non-Linear Sensors. The 
difference between the two types is mainly in the manner in which software that accesses the sensors needs to 
handle the conversion of the sensor readings. 


Sensor Devices are allowed to implement their sensors using ‘raw’ values for their thresholds and for returning their 
readings. For example, the physical device that implements a voltage sensor will often be an A/D converter. The 
values that the Sensor Device returns will typically be in A/D counts, rather than an direct integer value in volts. 


Therefore, software that interfaces to these values must know how to convert and interpret these values. The 
‘conversion factors’ for these values shall either be provided in the Sensor Data Record for the sensor, or shall be 
retrievable from the Sensor Device. In the example of the previous paragraph, the Sensor Data Record for the 
voltage sensor would contain values that allow software to convert those A/D counts to a voltage value. 


Allowing the sensor values to be isolated from the measurement units allows the Sensor Devices themselves to be 
implemented in a simpler manner. The measured quantity can also be changed or measurement adjusted by changing 
the Sensor Data Record without having to change the physical implementation of the Sensor Device. A physical 
instantiation of a Sensor Device that implement a sensor that’s an A/D converter could have that sensor defined as a 
voltage measurement sensor in one system implementation, and a current sensor in another. 


36.1 Linear and Linearized Sensors 


Linear sensors return readings that can be converted to the desired sensor units (temperature, voltage, etc.) using a 
linear conversion formula. Linearized sensors are sensors that can have one of a set of pre-specified conversion 
formulas applied to the reading to linearize it. After linearization the sensor reading can be converted to final units 
as if it was linear in the first place. 


Linear and Linearized sensors are also considered as having constant Accuracy, Tolerance, and Resolution over 
the range of the raw readings from the sensor. Thus, for a linearized sensor, the effects of accuracy, tolerance, and 
resolution are to be applied prior to application of the linearization formula. 


36.2 Non-Linear Sensors 


Non-linear sensors are sensors that either cannot be linearized using one of the pre-determined linearization 
formula, or are sensors that do not have constant conversion factors, accuracy, tolerance, and/or resolution over 
the range of their raw readings. 


Because the conversion factors, accuracy, etc., can vary - System Management Software must treat non-linear 
sensors by obtaining these factors for the reading of interest by querying the sensor using a ‘Get Sensor Reading 
Factors’ command. This means that polling of non-linear sensors is a two-step process. First, System Management 
Software obtains the raw reading from the sensor, second it issues a ‘Get Sensor Reading Factors’ command to 
retrieve the conversion factors for that reading. 


Since the conversion factors, accuracy, tolerance, etc., are returned with the reading, a linearization function is not 
applied in the conversion. 
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36.3 Sensor Reading Conversion Formula 


The following presents the formula used for converting ‘raw’ sensor readings for linear and linearized sensors to 
real values in the desired ‘units’ for the sensor (e.g. Volts, Amps, etc.). 


y = L[(Mx + (B * 1041) ) * 10*2] units 
where: 
x Raw reading 
y Converted reading 


L[] Linearization function specified by ‘linearization type’. 
This function is ‘null’ ( y = f(x) = x ) if the sensor is linear. 


Signed integer constant multiplier 
B Signed additive ‘offset’ 
K1 Signed Exponent. Sets ‘decimal point’ location for B. This is called the ‘B’ exponent in the SDRs. 


K2 Signed Result Exponent. Sets ‘decimal point’ location for the result before the linearization function 
is applied. This is called the ‘R’ exponent in SDRs. Linear and Linearized readings have constant 
accuracy, tolerance, M, and B factors regardless of the reading. 


Accuracy, tolerance, M, and B for ‘Non-linear’ sensors are only valid at the nominal reading. Otherwise, these 
factors must be obtained by ‘querying’ the sensor for these factors at the reading of interest using the ‘Get Sensor 
Reading Factors’ command. Refer to Section 35.5, Get Sensor Reading Factors, for more information. 


36.4 Resolution, Tolerance and Accuracy 


Resolution, Tolerance, and Accuracy are applied to the RAW reading for Linear and Linearizable sensors, prior to 
the application of any further conversion formula. 


36.4.1 Tolerance 


Tolerance is specified in the Sensor Data Records in +/- V raw counts. The +/- implies that the tolerance value 
is ‘0’ based. There is no ‘B’ offset used in converting the tolerance value to units. Tolerance can thus be 
converted to the to units using the formula y = L[Mx/2 * 10K2 ] units. Where L, M, and K2 are as specified 
above. 


Note that tolerance can vary at each reading for a non-linear sensor. The “Get Sensor Reading Factors’ 
command can be used to obtain the tolerance at a given reading. 


36.4.2 Resolution 


Resolution indicates the separation in units between successive raw reading values. For linear sensors, 
resolution is obtained from the ‘M’ factor. To convert M to resolution in units, use the formula y = abs(M * 
102) units. Where abs( ) means use the absolute value. 


36.4a Resolution for Non-linear & Linearizable Sensors 


The resolution typically varies at each different reading value of a non-linear or linearizable sensor. One 
approach to determining a resolution for these types of sensors is to examine the points neighboring the reading 
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of interest. Le. for reading ‘x’, take the difference between x and x+1 converted to units as the resolution in the 
‘positive’ direction, and the difference between x and x-1 converted to units as the resolution in the ‘negative’ 
direction. 


36.4b Offset Constant Relationship to Resolution 


There is a relationship between the constant offset factor, ‘B’, and resolution. For example, if a voltage sensor 
has a resolution of 100 mV and a zero ‘B’ offset, the raw readings and threshold settings from the sensor would 
convert to units in even increments of 100 mV. E.g. starting from 0: 0.000V, 0.100V, 0.200V, etc. If the same 
sensor had a ‘B’ offset equivalent to 2.250V, then the same readings would be 2.250V, 2.350V, 2.450V, etc. 


This may need to be incorporated into the user interface for a management application that displays readings, or 
allows thresholds to be set. For example, the user interface could provide a scrolling selection for threshold 
settings in units that incremented and decremented according to the specified offset and resolution values. 


36.5 Management Software, SDRs, and Sensor Display 


Analog sensor devices are always accessed using raw values, where the term ‘raw values’ refers to the fact that 
values from the sensor are not in the final assigned units. For example, an analog-to-digital converter returns a 
number that is representative of a voltage applied to the device. Whether that voltage represents temperature or 
fan speed is dependent on how the device is applied. 


If a Get Sensor Reading command is issued to a management controller that provides the A/D converter reading, 
the management controller will typically just return the direct reading from the converter. Software uses the 
conversion factors in the SDR for the sensor to convert that reading to units that the platform vendor or system 
integrator selected as being appropriate for the device. The selection of one type of unit versus another is typically 
made according to what best fits the monitoring hardware and maintains the best accuracy. 


Thresholds and threshold comparisons are also done with raw values. The threshold designations “Upper” and 
“Lower” are solely with respect to the hardware that is doing the comparison of the thresholds with the raw 
reading values. Correspondingly, the Upper and Lower threshold values in the SDRs reflect these raw values. The 
upper threshold is always for the raw reading with the most positive value, the lower threshold with the most 
negative value. This is not necessarily the value with the greatest absolute magnitude. E.g. if I have two threshold 
values, 5 and 10, 5 would be the lower threshold and 10 would be the upper. If I have -5 and 10, -5 would be the 
lower, and 10 would be the upper. If I have -5 and -10, however, -10 would be the lower threshold and -5 the 
upper - since -5 is more positive than -10. 


36.5.1 Software Display of Threshold Settings 


In most cases, software can directly display thresholds directly after performing the conversion to units. There is 
a set of cases, however, where it is recommended that software display the thresholds with the upper and lower 
threshold names ‘swapped’ in order to provide a more intuitive user interface. This can occur with sensors that 
have a 1/x Linearization factor, as described in the following example. 


Suppose I have a ‘tach fan’ that outputs a number of pulses per fan revolution, and a sensor that returns a raw 
reading that is directly proportional to the period (interval) between the pulses. As the fan speeded up, the 
reading would decrease (since the interval between pulse would get smaller) and as the fan slowed down the 
pulse period would increase. The following shows some example ‘raw value’ thresholds that might be returned 
by such a sensor. 


Sensor Hardware Settings (raw units): 
Upper Critical going high Threshold = 100 (Fan going too slow) 


Lower Critical going low Threshold = 10 (Fan going too fast) 
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An SDR could be made that directed software to convert and report this period in terms of seconds. For 
example, the SDR could contain linear conversion factors that converted the reading into seconds. In this 
example, assume a reading of 100 corresponds to 100 milliseconds, and a value of 10 corresponds to 10 
milliseconds. The user interface may then present the following information: 


Software User Interface Display: 

Sensor Type: Fan 

Upper Critical Threshold: 100 ms 

Lower Critical Threshold: 10 ms 
While correct, this display is not particularly intuitive to the end user. The user would probably make more 
sense of the values if they were given in RPM. Thus, a more ‘user friendly’ SDR would direct software to 
present the reading as RPM. To do this requires converting the raw reading using a 1/x linearization factor, 
either in the SDR or done by the system management software. In this example, assume the fan puts out 1 pulse 
per revolution. A 10 ms interval would correspond to 1 revolution in 10 ms, which equals 100 revolutions per 


second, or 6000 revolutions per minute (6000 RPM). Similarly, a 100 ms interval would correspond to 600 
RPM. 


In this case, a piece of user interface software that displayed the threshold settings directly by applying the 
conversion factors would see: 


Software User Interface Display: 
Sensor Type: Fan 

Upper Critical Threshold: 600 RPM 
Lower Critical Threshold: 6000 RPM 


While this is correct with respect to the management controller that is doing the comparisons, an end user may 
be confused to see a Lower Critical Threshold value that is greater than the Upper Critical Threshold. Thus, 
it’s recommended that the User Interface swap the threshold names when the 1/x factor is encountered. This 
will allow the end user to see the thresholds presented as: 


Software User Interface Display: 
Sensor Type: Fan 


Upper Critical Threshold: 6000 RPM 
Lower Critical Threshold: 600 RPM 


This presentation of fan speed thresholds is likely to make more sense to the typical user. 


36.5.2 Notes on Displaying Sensor Readings & Thresholds 


The following should be kept in mind when designing software that utilizes SDRs for the display for sensor 
readings and thresholds: 


e ‘Analog’ sensor readings and thresholds use raw values. 
e Thresholds in sensors and SDRs are given in raw values. 


e The management controller performs its threshold comparisons are done against raw values. Changing the 
SDR has no effect on the meaning of Upper and Lower as far as the management controller is concerned. 


e Changing the units and conversion factors for a sensor does not change the hardware behavior. 
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Sensor Data Records tell software how to convert the raw values into units that the platform vendor or 
system integrator deemed appropriate for the sensor. The values are typically selected based on what 
provides the most accurate or direct conversion of the hardware. 


System software can elect to convert units for display to the user. For example, system software may elect 
to display all temperatures in Fahrenheit, even if the Sensor Data Record provides factors for converting the 
reading to Celsius. 


To make the display more intuitive to the user, it’s recommended that software swap the threshold names 
when linearization or conversions factors, e.g. 1/x, cause the sense of ‘Upper’ and ‘Lower’ to be reversed 
during the conversion from raw values to display units. 


The System Event Log also returns values in raw units, and thresholds that are related to raw units. System 
Events are best displayed when the SEL Record information is combined with the SDR information for the 
sensor. The meaning of Upper and Lower threshold events cannot be fully understood without using the 
SDR information. For example, it’s possible that an ‘Upper Critical’ temperature event could actually 
correspond to a LOW TEMPERATURE. Thus, if a System Event Log display utility doesn’t have access to 
the SDR information, it’s best to emphasize the criticality and sensor type associate with the event rather 
than what particular threshold was crossed. 


Intelligent Platform Management Interface Specification 
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37. Timestamp Format 


Timestamping is a key part of event logging and tracking changes to the Sensor Data Records and the SDR 
Repository. The following specifies the format of the seconds-based timestamp used in this document. 


Time is an unsigned 32-bit value representing the local time as the number of seconds from 00:00:00, January 1, 
1970. This format is sufficient to maintain timestamping with 1-second resolution past the year 2100. This is based 
on a long standing UNIX-based standard for time keeping, which represents time as the number of seconds from 
00:00:00, January 1, 1970 GMT. Similar time formats are used in ANSI C. 


The timestamps used for SDR and SEL records are assumed to be specified in relative local time. That is, the 
difference between the timestamp does not include the GMT offset. To convert the timestamp to a GMT-based time 
requires adding the GMT offset for the system. (The GMT offset needs to be obtained from system software level 
interfaces, there is no provision in the IPMI commands for storing or returning a GMT offset for the system.) 
Applications may use ANSI C time standard library routines for converting the SEL timestamp reading into other 
time formats. Be aware that this may require additional steps to account for the system”s GMT offset. 


37.1 Special Timestamp values 


OxFFFFFFFF indicates an invalid or unspecified time value. 


0x00000000 through 0x20000000 are used for timestamping events that occur after the initialization of the 
System Event Log device up to the time that the timestamp is set with the system time value. Thus, these 
timestamp values are relative to the completion of the SEL device’s initialization, not January 1, 1970. 
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38. 


Accessing FRU Devices 


FRU devices can either be located behind a management controller or located directly on the IPMB. The sensor data 
records include a FRU Device Locator record that tells software where the device is located and what type of 
commands are required to access the FRU device. FRU devices can located in three different types of location: 


Behind a management controller and accessed using Read/Write FRU Data commands. Multiple FRU 
devices can be behind a management controller. The Read/Write FRU Data commands include a FRU 
Device ID field that is used to identify individual FRU devices on the given LUN in the management 
controller. Up to 255 FRU devices can be located on a given LUN. FRU Device ID #00 at LUN 00b is pre- 
defined as being the FRU Device for the FRU that the management controller is located on. Since there are 
four possible LUNs for a management controller, this means up to 255*4 FRU devices can be supported 
behind a single management controller using this mechanism. The Read/Write FRU Data commands 
provide an abstracted interface that hides the technology used to implement the FRU device from system 
software. 

SEEPROM on a private bus behind a management controller. These devices are accessed using Master 
Write-Read commands. System software needs to know the operation of a 24C02-compatible SEEPROM 
interface to access these devices. 

SEEPROM on the IPMB. These devices are typically accessed using a Master Write-Read command to the 
IPMB via the BMC. System software needs to know the operation of a 24C02-compatible SEEPROM 
interface to access these devices. Note that there are only eight IPMB addresses available for typical 
24C02-type SEEPROM devices, four of which are reserved for the baseboard supplier. (Refer to the IPMB 
Address Allocation specification). 


The FRU Device Locator record provides fields that identifies the type of location for the FRU Device and where 
it’s located. The following table illustrates how these fields are used. 
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Table 38-, FRU Device Locator Field Usage 


FRU Device Type and 
Location FRU Device Locator Fields Access Method 


FRU Device Accessed via Device Access Address: IPMB Slave address of the Read / Write FRU Data 
Read/Write FRU commands to controller that accepts the commands to management 
management controller Read/Write FRU Data controller providing access to 
commands for access the the FRU Device. 
FRU Device. 


FRU Device ID / FRU Device ID. 
Device Slave Address: 


Access LUN / Bus ID: bit 7 = 1 indicates device is 
access using Read/Write FRU 
Data commands. 
bits 4:3 hold the LUN to send 
the Read/Write FRU Data 
commands to. 
bits 2:0 = 000b. (no private 
bus ID) 


SEEPROM On private bus Device Access Address: IPMB slave address of the Master Write-Read command 
behind a management controller to send the Master to management controller that 
controller Write-Read command to. provides access 


FRU Device ID / Slave address of the to the private bus 

Device Slave Address: SEEPROM on the private bus. 
Used in the Master Write- 
Read command. 

Access LUN / Bus ID: bit 7 = 0 indicates device is a 
non-intelligent device. 
bits 4:3 hold the LUN to send 
the Master Write-Read FC 
command to. 
bits 2:0 hold the Private Bus 
ID to use in the Master Write- 
Read command. 


SEEPROM Device directly on Master Write-Read command 
IPMB directly on IPMB through BMC from 
FRU Device ID / Slave address of the system software, or access via 
Device Slave Address: SEEPROM on the IPMB. other interface providing 


Access LUN / Bus ID: bit 7 = 0 indicates device is a low-level I?C access to the 
non-intelligent device. IPMB. 


bits 3:0 = Oh indicates device 
is on the IPMB. 
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39. Using Entity IDs 


An Entity ID is a standardized numeric code that is used in SDRs to identify the types of physical entities or FRUs 
in the system. The codes include values for entities such as Processor, Power Supply, Fan, etc. The Entity ID values 
are specified in Table 43-13, Entity ID Codes. 


The Entity ID is associated with an Entity Instance value that is used to indicate the particular instance of an entity. 
For example, a system with four processors would use an Entity Instance value of ‘0’ to identify the first processor, 
“1” for the second, and so on. [Note: The assignment of Entity Instance values is up to the implementer. There's no 
predefined semantics on the Entity Instance other than its use to differentiate among Entities of the same type. For 
example, an implementer could designate the first processor using Entity Instance 0, 1, or 12...] 


The SDR for a sensor includes Entity ID and Entity Instance fields that identify the entity associated with the sensor. 
This allows system software to tell a temperature sensor associated with ‘Processor 1” from a temperature sensor 
associated with ‘Power Supply 2’. The use of numeric codes facilitates the development of automated applications 
that act on this relation information. It also supports internationalization and localization. 


39.1 System- and Device-relative Entity Instance Values 


Entity Instance values can be in one of two ranges, system-relative or device-relative. In IPMI v1.0, all Entity 
Instance values were system-relative - meaning that the Entity Instance numbers for a given had to be unique for 
all entities in the system sharing the same Entity ID. A problem with this approach is that add-in cards and 
management controllers cannot have pre-assigned Entity Instances because of the potential that those values 
would overlap with Entity Instance values already present in the system. 


In order to correct this situation, the IPMI v1.5 specification splits the Entity Instance value into two ranges. 
Entity Instance values in the system-relative range are required to be unique for all entities with the same Entity 
ID in the system. Device-relative Entity Instance values are only required to be unique among all entities that have 
the same Entity ID within a given device (management controller). For example, management controller ‘A’ and 
‘B’ could both have FAN entities that have and Entity Instance value of ‘60h’. 


The system-relative Entity Instance definition matches the original Entity Instance definition in IPMI v1.0. 
Therefore an IPMI v1.0 implementation that is being migrated to IPMI v1.5 does not need to change Entity 
Instance values if they’re already in the system-relative range. 


Table 39-, System and Device-Relative Entity Instance Values 


Range Name Definition 


00h-5Fh | system-relative | The Entity Instance number must be unique for each different entity of the same type 
Entity ID in the overall system. 


60h-7Fh | device-relative | Instance number is unique for each different entity of type Entity ID only relative to the 
particular management controller device that provides access to the sensors for the 
entity. The entity is uniquely identified at the system level by the combination of the 
Sensor Device number and the Entity Instance number. 


It is recommended that console software subtract 60h when presenting device-relative 
Entity Instance values, and present the Entity Instance number along with an ID for the 
device providing the interface to the entity. For example, suppose management 
controller ‘1’ had a FAN entity with a device-relative Entity Instance value of 61h. It may 
make more sense to the user to refer to the entity as “Controller 1, Fan 1” than 
‘Controller 1, Fan 61h’. Entities with system-relative Entity Instance values could be 
preceded with the word ‘System’ (or something similar). E.g. “System, Fan 1.” 


39.2 Restrictions on Using Device-relative Entity Instance Values 


Note that when using a Sensor Device Relative instance number, all sensors monitoring a given entity must be 
provided via one management controller. Otherwise, it may appear that there are more instances of the entity than 
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are actually present. For example, suppose an add-in card has a single fan where current is monitored via sensor 1 
in management controller ‘A’ and the speed monitored via sensor 2 in management controller ‘B’. Because the 
management controller’s ID is now part of what uniquely identifies the entity, software would view these sensors 
as monitoring different fans, even if the Sensor Device Relative instance number were the same. 


39.3 Sensor-to-FRU Association 


A given Entity may itself be a FRU. In this case the Entity ID can be used to look up the FRU Device Locator 
record for that Entity. (The FRU Device Locator record is a type of SDR that identifies the location and type of 
FRU Devices in the platform management subsystem). The following figure presents an example illustrating the 
steps that system management software could use to locate and access the FRU for the Entity associated with a 
sensor. 


Figure 39-, Sensor to FRU Lookup 


O System software finds an event for sensor number 12 in a 
management controller with IPMB address 22h. System 
management software desires to report the serial number of the 
FRU that is associated with the event. System management 
software first looks up the SDR for the sensor by searching for 
the SDR for sensor #12 and mgmt. controller with IPMB 
address 22h: 


Sensor Data Record FRU Device Locator Memory Module 


Sensor Owner ID = 22h Fe 
Sensor Number = 12h m~~ Entity ID = Memory Module Gei addr = = 
Entity Instance = 1 Entity Instance = 1 "A" 
Look Up || Device Access Addr. = 20h (BMC) Private Bus 01 
FRU Device ID / Device Slave BMC 
Address = A2h (slave addr 20h) |* 


Access LUN / Bus ID = 0xxx0000b. 
bit 7 = 0 (device is non-intelligent 
device) 

Access LUN = 00b 

Bus ID = 01b (private bus #1) 


Entity ID = Memory Module 


System Interface 


Entity Instance = 1 


`N System mgmt. software extracts FRU device 
`~ location from FRU Device Locator record. It 


(5 N System mgmt. software uses Entity ID and Entity 
NE Instance fields in SDR to look up the 


corresponding FRU Device Locator Record. If 
there's no FRU Device Locator record for that 
Entity, the entity may be a logical entity 
represented via an Entity Association record. 


determines the device is a FRU SEEPROM on 
a private bus behind the BMC. It then 
accesses the device by sending Master Write- 
Read DC command to BMC LUN 00b using 
A2h as the slave address parameter, and 01 
as the private bus ID parameter. System 
software then walks the FRU fields and 
extracts the serial number from the Board Info 
area in the FRU Device. 


System Software 
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40. Handling Sensor Associations 


This section presents information on handling the relationships between Entities and sensors. 


40.1 Entity Presence 


Multiple sensors can be associated with the same Entity. For example, a voltage sensor, temperature sensor, and 
processor sensor can all be associated with the same Processor I entity. This forms a simple association among 
the sensors. 


Some entities, such as processors, have sensor-specific discrete sensor types that include presence as part of their 
definition. If the Entity has a presence status associated with it, system management software should ignore 
sensors and other status associated with the Entity when the Entity is absent. A bit in the SDR for each sensor 
indicates whether the sensor should be ignored when the associated Entity is absent or disabled. 


For other entities, an Entity Presence sensor can be defined. This sensor is always implemented as a generic 
discrete sensor using an Event/Reading Type code of 08h, for Device Absent/Device Present, or 09h for Device 
Enabled/Disabled. 


40.2 Software detection of Entities 


This section describes steps that software can use to detect the presence of an Entity. There are several ways to 
detect the presence of an Entity. Software can determine that an Entity is present by the existence of a FRU device 
for the entity, active sensors for that entity, by the state of a 'presence' bit for the sensor, or by an Entity Presence 
sensor for the entity: 


e An Entity is present or absent if there is an active sensor that holds an explicit present bit or presence 
sensor that indicates the presence/absence of the Entity. Presence/absence bits and presence sensors take 
precedence over all other presence determination mechanisms. 


e An Entity is present if the FRU Device for that Entity exists (can be accessed) - unless overridden by an 
explicit presence bit or Entity Presence sensor indicating that the entity is absent. 


e An Entity should be assumed absent if the Entity Presence sensor for the entity is inaccessible, or the Entity 
is part of an Entity Association under an inaccessible Entity Presence sensor. This provision allows the 
entity presence sensor to represent the presence of a collection of entities. Software should then ignore any 
sensors associated with absent entities. 


e An Entity is present if there is at least one active sensor for the Entity (and there is no explicit sensor saying 
the Entity is absent), A sensor is ‘active’ if scanning is enabled. For each of these sensors, check to see that 
at least one of the sensors is scanning by checking the "sensor scanning disabled" bit via the Get Sensor 
Reading command. Per section 11.5, software should ignore this bit if its set to ‘disabled’. If there are no 
active sensors for the entity, then it should be assumed that the Entity is absent. 


e An Entity is assumed present if the entity is a 'container' entity in an entity association, and at least one of 
the 'contained' entities is present. For example, suppose there is a power unit' entity that is a container 
entity for three power supply entities. Then the power unit entity is present if any of the power supply 
entities are present. 


e For a container entity that has a presence sensor associated with it, if the presence sensor indicates the 
container entity is absent, software should consider the contained entities and associated sensors as also 
being absent. Note that some software may not interpret Entity-association records. Therefore, if a given 
sensor is described in the SDRs and remains accessible when the container entity is absent, either the 
sensor should return “scanning disabled’ or, if the sensor has a presence bit, should return that the 
monitored entity is ‘not present’. 
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Thus, the steps to detecting an Entity are: 
a) Scan the SDRs for sensors associated with the entity. 


b) If there is an active sensor that includes a presence bit, or the entity has an active Entity Presence sensor, 
use the sensor to determine the presence of the entity. 


c) Otherwise, check to see that there is at least one active sensor associated with the entity. Do this by doing 
Get Sensor Readings' to the sensors associated with the entity until a scanning sensor is found. 


d) If there are no active sensors directly associated with the entity, check the SDRs to see if the entity is a 
container entity in an entity-association. If so, check to see if any of the contained entities are present, if so, 
assume the container entity exists. Note that this may need to be iterative, since it's possible to have multi- 
level entity associations. 


e) Ifthere are no active sensors for the entity, and the entity is not the container entity in an active entity- 
association, then the entity is present is there is a FRU device for the entity, and the FRU device is present. 


It should not be considered an error if a FRU device locator record is present for a FRU device, but the FRU 
device is not there. This is because there may be a presence sensor that indicates the FRU is absent. It would only 
be an error if there was an active sensor or entity-association that was associated with the Entity, and the FRU 
device for the Entity wasn't there. 


40.3 Using Entity Association Records 


Entity Association Records allow multiple physical entities to be grouped into a single logical entity. (Note, the 
structure also allows logical entities to be comprised of other logical entities...) This grouping is typically used for 
defining a logical entity that has sensing associated with it that relates to the physical entities that comprise the 


group. 


For example, in a system with redundant power supplies, a Power Unit can be viewed as a logical entity 
comprised of multiple Power Supply entities. The Entity Association Record can be used to tell system 
management software which Power Supply entities make up the power unit. The association also allows system 
management software to correlate failures from individual entities with status of the logical entity. 


Continuing with the Power Unit example, suppose the Power Unit had a discrete sensor that returned Redundancy 
Status (Redundant, Redundancy Degraded, Non-Redundant, etc.), and that each individual Power Supply had a 
sensor that returned a failure status. System management software could use the association to correlate a change 
in the Power Unit redundancy status with a corresponding failure of a Power Supply in the Power Unit. 


The Entity Association record also allows physical entities to be grouped to indicate that a single sensor applies to 
multiple entities. For example, a voltage regulator could be shared among pairs of processors. Logical grouping of 
entities can be handled in one of two ways. The first is to use bit 7 in the Entity Instance field. This bit indicates 
whether a particular entity should be viewed as a logical ‘group’ entity rather than by its base definition in the 
Entity ID table. 


For example, if the Entity was ‘Processor 1’, setting this bit would tell software to consider the entity as 
‘Processor Group 1” instead. The Entity Association record corresponding to this logical entity could then consist 
of contained processor entities (by convention, a logical processor group only contains processor entities - though 
this is not mandatory.) 


If this way of identifying a grouping is not sufficient, there is a generic ‘Group’ Entity ID that is provided solely 
to serve as the container entity for grouping of entities that do not fall under a specific logical Entity ID type. 


It is thus possible to present several types of relationships between sensors and entities. With a direct Sensor-to- 
entity relationship (no Entity Association record involved) a typical sensor-to-entity relationship would be: 


“Power Supply 1 Temperature Sensor ” 
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While with an Entity Association for a pre-defined logical entity a possible relationship would be: 
“Redundancy Sensor for Power Unit 1 containing Power Supply 1, Power Supply 2, and Power Supply 3” 
The Entity Association for a logical group relationship would be: 
“Voltage Sensor for Processor Group | containing Processor | and Processor 2” 
Lastly, the Entity Association, a generic Group relationship could be: 
“Voltage Sensor for Group 2 containing Processor | and Fan 2” 


It is recommended that console software subtract 60h when presenting device-relative Entity Instance values, and 
present the Entity Instance number along with an ID for the device providing the interface to the entity. For 
example, suppose management controller ‘1’ had a FAN entity with a device-relative Entity Instance value of 
61h. It may make more sense to the user to refer to the entity as “Controller 1, Fan 1” than ‘Controller 1, Fan 
61h’. Entities with system-relative Entity Instance values could be preceded with the word ‘System’ (or 
something similar). E.g. “System, Fan 1.” 
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41. Sensor & Event Message Codes 


This section provides a description of the Sensor and Event Codes and the manner in which they are used within 
Sensor Data Records and Event Messages. Following is a series of tables that define these codes. 


41.1 Sensor Type Code 


Each sensor has a Sensor Type Code. These codes are defined in Table 42-, Sensor Type Codes. Sensor Type 
Codes are used both in SDRs and Event Messages. An example of a Sensor Type Code is code 07h, which 
indicates a Processor sensor. 


41.2 Event/Reading Type Code 


The Event/Reading Type Code is used for specifying the types of readings that a sensor can provide, the types of 
events that a sensor can generate, and the type of state or transition that triggered an event. 


Event/Reading Type Codes are split into three categories: 


Generic 


Sensor Specific 


OEM 


The Event/Reading Type Code specifies one of a set of pre-defined enumerations that are 
applicable to many different types of sensors. It is expected that system software will have 
a-priori knowledge of how to interpret these types of states and events. As such, these 
enumerations should be used whenever possible. For example, an Event/Reading Type 
Code of 02h identifies the “DMI Usage State” enumeration, which consists of three 
members “(transition to) Idle”, “(transition to) Active”, and “(transition to) Busy”. This 
enumeration can be represent either a an event or state change (e.g. “transition to Idle”) or a 
state (e.g. “Idle”) - based on the context in which it is used. 


An Event/Reading Type Code of 6Fh indicates that the enumeration is defined explicitly for 
the particular Sensor Type. In an event message, an Event Dir bit of ‘0’ indicates the state 
has become asserted, while an Event Dir bit of ‘1’ indicates the state has become 
deasserted. For example, if the Sensor Type Code were 07h, “Processor”, then an 
Event/Reading Type Code of 6Fh would indicate that the offsets specified in the Sensor 
Type Codes table for “Processor” are to be used. A ‘0’ Event Dir bit with an event offset of 
07h (processor presence) would indicate that the event was generated because a processor 
has become present (inserted). If the Event Type Code were 6Fh, but the Event Dir bit was 
1, the same 07h offset would indicate that the event was generated because the processor 
had become not present (removed). 


The advantage of the Sensor Specific enumeration is that it provides state and/or event type 
information that is ‘customized’ to the particular sensor. The disadvantage is that System 
Management Software requires a-priori knowledge of these enumerations in order to make 
use of them. Thus, this type of enumeration is used sparingly. 


These Event/Reading Type Codes indicate that the sensor enumeration is OEM defined. It 
is used in conjunction with a non-OEM Sensor Type Code as a way of specifying an OEM- 
defined enumeration for a standard sensor type. This type of Event/Reading Type Code 
should be avoided where possible. Making use of it requires a-priori knowledge of the 
OEM-defined enumeration. Since multiple OEMs could define their own enumerations 
under the same code, software needs to use the OEM ID (Manufacturer ID) information 
along with the Event/Reading Type code to correctly interpret the code. The Manufacturer 
ID value is obtained by issuing a Get Device ID command to the controller that generated 
the event or owns the sensor identifies the OEM. 


When event/reading offset values are returned as sensor readings (using the Get Sensor Reading command) they 
represent the present state of the sensor. For example, for the offset that is described as “Transition to Idle” the 
present state for the asserted condition of the offset would be interpreted as “Idle”. In some cases, the 
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event/reading code also includes information that implies the previous state from which the present state was 
entered. For example, the generic event/reading type code for the “Severity Event States” includes offsets such as 
“Transition to Non-critical from OK”. However, when the platform management subsystem is initialized, the 
BMC may not know what the previous state was. In the case that the BMC cannot determine the previous state of 
the sensor, or an appropriate offset is not provided, it can return any offset that shows the correct current state. 


By convention, if the previous state is unknown and there is a choice of possible offsets for the present state most 
implementations will return the offset that corresponds to a previous state that is ‘OK’. For example, it would 
return the offset for “Non-critical from OK” rather than “Non-critical from more severe”. This is not a 
requirement, however. Therefore, since the actual previous state may be unknown, it is recommended that 
management software ignores the ‘directionality’ information inferred by the offset for the present reading. For 
example, when interpreting the present reading for the “Severity Event Status” it should present the present state 
just as “Non-critical” and ignore the ‘from OK / from more severe’ aspect associated with the offset. 


If software cares about the transition direction associated with entering a given present state, it should get that 
information from the sensor event status (using the Get Sensor Event Status command). If a sensor returns ‘0b’ 
values for both assertion and deassertion offsets in the Get Sensor Event Status command, it means that the sensor 
has been initialized with the previous state unknown. Le. there have been no detected state transitions yet that 
would cause the event status bits to become set. In this case, it is clear that there is no ‘directionality’ information 
available and software should generally ignore any ‘directionality’ that is implied by the present reading. 


41.3 SDR Specification of Event Types 


The SDR uses an Event/Reading Type Code in the Event/Reading Base Code field to identify the particular 
enumeration of states or transitions for which the sensor will generate an event. Often, the events that a sensor 
generates will be only a subset of the enumerated events. Thus, the Event/Reading Base Code is coupled with an 
‘Event Mask Field’ that identifies which elements of the enumeration could actually generate events. 


The Assertion Event Mask field is used in the following manner. Suppose the SDR for a sensor has an 
Event/Reading Base Code field of 02h, “DMI Usage State”. According to the Event/Reading Type Code tables, 
this value indicates that the sensor produces discrete events of the generic event enumeration Transition to Idle, 
Transition to Active, Transition to Busy. If the Assertion Event Mask field is 000000000101b this indicates that of 
those three possible events in the enumeration, the Transition to Idle and Transition to Busy events may be issued 
by the sensor, but the Transition to Active event will not. The Deassertion Event Mask is used the same way, but 
to indicate events on the deassertion, rather than assertion, of a state. 


41.4 SDR Specification of Reading Types 


The SDR has bits that indicate whether the sensor returns a ‘present reading’ or not. If it does, it also indicates 
whether the returned reading is discrete or threshold-based, and if an 8-bit analog (multilevel) value is returned. 


If the sensor returns an analog reading, additional information such as the raw data format, units, and conversion 
factors for the reading are specified in other fields of the SDR. System Management Software can use these values 
for converting the reading from the sensor into units such as volts, degrees centigrade, etc. 


If the sensor returns a discrete reading, the Event/Reading Type Code is used for specifying the possible states 
that can be returned. For these sensors, the Reading Mask field indicates which possible states could be returned 
from the sensor as a present reading in the same manner that the Assertion Event Mask and Deassertion Event 
Mask fields are used to indicate states that can generate events. 


Note that, by convention, the events that a discrete sensor generates must be a subset of the readable states. 


41.5 Use of Codes in Event Messages 


When a sensor generates an Event Message, the Event/Reading Type Code and corresponding event enumeration 
‘offset’ will be returned in the Event Message. The Event/Reading Type Code is returned in the Event Type field, 
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and the enumeration offset value is returned in a bit field in the Event Data field. An additional, optional, offset to 
the ‘Severity’ enumeration offsets may also be provided if the sensor class is discrete or OEM. In these cases, the 
base Event/Reading Type Code is implied to be 07h, “DMI-based Severity”. 
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42. Sensor and Event Code Tables 


This section contains the tables that define the sensor and event code values used in SDRs and Event Messages. 


42.1 


Event/Reading Type Codes 


Event/Reading Type codes are used in SDRs and Event Messages to indicate the trigger type for an event. These 
codes are also used in SDRs to indicate what types of present reading a sensor provides. 


Event/Reading Type Codes are used to specify a particular enumeration (offset) that identifies a set of possible 
events that can be generated by a sensor. For discrete sensors, the specification of an Event/Reading Type code 
enumeration also indicates the type of reading the sensor provides. 


Sensors fall into the following classes: 


Sensor Classes: 
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Discrete 


‘Digital’ 


Threshold 


Multiple states possible. Discrete sensors can contain up to 15 possible states. For discrete 
sensors, the Get Sensor Reading command returns a bit field where each bit reflects a 
different state. It is possible for a discrete sensor to have more than one state active at a time. 


Discrete sensors can be designed to provide either Generic or Sensor-specific states. The 
Event/Reading Type Codes in Table 42- are used to specify the particular set of possible 
Generic states for a discrete sensor. Generic states may be applicable to many types of sensors 
- that is, a temperature sensor and a voltage sensor may both be implemented that return 
Severity states (Event/Reading Type Code 07h). 


For example, Event/Reading Type Code OBh indicates a discrete sensor that could return one 
of three possible states “Redundancy Regained, Redundancy Lost, or Redundancy Degraded”. 
The offsets from the table correspond to the bit positions in the Get Sensor Reading 
command. The offset values are also used in event messages and in event configuration. 
(Note, Event Messages reflect only one event at a time. Thus, Event Messages do not return a 
bit field, just a single offset value corresponding to a single event.) 


Sensor-specific states, however, are tied to a particular sensor type. The sensor-specific 
offsets are specified in the sensor types table: Table 42-, Sensor Type Codes. When the 
sensor-specific offsets are used in the SDR for a sensor, the Event/Reading Type Code 6Fh is 
used. This code is also used in Event Messages. An Event Dir bit in the Event Message 
indicates whether the event is an assertion or deassertion event. 


A digital sensor is not really a unique class, but a term commonly used to refer to special case 
of a discrete sensor that only has two possible states. Use the discrete sensor type when 
formatting commands and events for digital sensors. Table 42-, 04h is the Event/Reading code 
for a ‘digital’ sensor that has the possible generic states “Predictive Failure deasserted” and 
“Predictive Failure asserted”. If a Get Sensor Reading command returns an offset of ‘0’, then 
that means the present state is “Predictive Failure deasserted”. 


‘Threshold based’. Changes event status on reading comparison to threshold values. 
Threshold enumerations may be considered a special case of the discrete sensor type. The 
Event/Reading Type Code for threshold-based sensors is specified in Table 42-, Generic 
Event/Reading Type Codes, below. The offsets specify each particular possible threshold 
state. 


Threshold-based sensors return a different response to the Get Sensor Reading command than 
discrete sensors. The offsets The Get Sensor Reading command for a threshold-based sensor 
contains the present ‘analog’ reading from the sensor along in addition to the discrete 
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threshold comparison status bit field. 


OEM 


Special case of discrete where the meaning of the states (offsets) are OEM defined. 


Table 42-, Event/Reading Type Code Ranges 


7-bit 
Event/Reading 
Type Code 
Range 


Sensor 
Class 


Event/Reading 
Type Code 
category 


Description 


Event/Reading Type unspecified. 


Threshold-based. Indicates a sensor that utilizes values that represent 
discrete threshold states in sensor access and/or events. The 
Event/Reading event offsets for the different threshold states are 
given in Table 42-, Generic Event/Reading Type Codes, below. 


Generic Discrete. Indicates a sensor that utilizes an Event/Reading 


Threshold threshold 
u 


` 
ii 


Type code & State bit positions / event offsets from one of the sets 
specified for Discrete or ‘digital’ Discrete Event/Reading class in Table 
42-, Generic Event/Reading Type Codes, below. 

Sensor-specific Discrete. Indicates that the discrete state information 
is specific to the sensor type. State bit positions / event offsets for a 
particular sensor type are specified in the ‘sensor-specific offset’ 
column in Table 42-, Sensor Type Codes, below. 

OEM Discrete. Indicates that the discrete state information is specific 
to the OEM identified by the Manufacturer ID for the IPM device that is 
providing access to the sensor. 


Event/Reading Type Codes that are not explicitly specified in this table are reserved. 


Table 42-, 


Generic 
Event/Reading 
Type Code 


Event/Reading 
Class 


Threshold 


| 


er 
Oth State Asserted 
EER EE 
Oth Predictive Failure asserted 
Oth Limit Exceeded 
Oth Performance Lags 


00h 
Oth 
02h 


Generic Event/Reading Type Codes 


Generic 
Offset 


Description 
THRESHOLD BASED STATES 


Lower Non-critical - going low 
Lower Non-critical - going high 
Lower Critical - going low 

Lower Critical - going high 

Lower Non-recoverable - going low 
Lower Non-recoverable - going high 
Upper Non-critical - going low 
Upper Non-critical - going high 
Upper Critical - going low 

Upper Critical - going high 

Upper Non-recoverable - going low 
Upper Non-recoverable - going high 
DMI-based “Usage State” STATES 
Transition to Idle 

Transition to Active 

Transition to Busy 
DIGITAL/DISCRETE EVENT STATES 
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Generic 
Event/Reading Event/Reading Generic 
Type Code Class Offset Description 
SEVERITY EVENT STATES 


Discrete transition to OK 
transition to Non-Critical from OK 
transition to Critical from less severe 
transition to Non-recoverable from less severe 
transition to Non-Critical from more severe 
transition to Critical from Non-recoverable 
transition to Non-recoverable 
Monitor 
Informational 
AVAILABILITY STATUS STATES 


01h Device Inserted / Device Present 


Discrete transition to Running 
transition to In Test 
transition to Power Off 
transition to On Line 
transition to Off Line 
transition to Off Duty 
transition to Degraded 
transition to Power Save 
Install Error 


| Other AVAILABILITY STATUS STATES | 


Discrete Redundancy I oe | Discrete | | Redundancy States 1 
Fully Redundant (formerly “Redundancy Regained”) 


Indicates that full redundancy has been regained. 
Redundancy Lost 

Entered any non-redundant state, including Non- 
redundant:Insufficient Resources. 


Redundancy Degraded 

Redundancy still exists, but at a less than full level. For 

example, a system has four fans, and can tolerate the 

failure of two of them, and presently one has failed. 

Non-redundant:Sufficient Resources from Redundant 

Redundancy has been lost but unit is functioning with 

minimum resources needed for ‘normal’ operation. 

Entered from Redundancy Degraded or Fully Redundant. 

Non-redundant:Sufficient Resources from Insufficient 

Resources 

Unit has regained minimum resources needed for ‘normal’ 

operation. Entered from Non-redundant:Insufficient 

Resources. 

Non-redundant:Insufficient Resources 

Unit is non-redundant and has insufficient resources to 

maintain normal operation. 

Redundancy Degraded from Fully Redundant 

Unit has lost some redundant resource(s) but is still in a 

redundant state. Entered by a transition from Fully 

Redundant condition. 

Redundancy Degraded from Non-redundant 

Unit has regained some resource(s) and is redundant but 

not fully redundant. Entered from Non-redundant:Sufficient 

Resources or Non-redundant:Insufficient Resources. 
Discrete ACPI Device Power States 

DO Power State 

D1 Power State 

D2 Power State 

D3 Power State 
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42.2 Sensor Type Codes and Data 


The following table provides the specification of the Sensor Type values and sensor-specific event offsets (if any). 
Note that generic offsets can be used with any Sensor Type even if the sensor has a definition for sensor-specific 
offsets. For example, a Processor sensor could be implemented that uses a Generic Event/ReadingType Code of 


OAh to provide a sensor that indicates whether a 
Event/Reading Type Code OAh). 


processor has entered a degraded state (offset 06h for 


Table 42-, Sensor Type Codes 


reserved | oon | - Lresenei i 
| Temperature | on | | Temperature S 
[Voltage [om | - [Voltage o 


Sensor Sensor- 
Type specific 
Sensor Type Code Offset 


Current | oof -~ | 


Fan 


Physical Security 
(Chassis Intrusion) 


Platform Security 
Violation Attempt 


Processor 


Fan 

General Chassis Intrusion 

Drive Bay intrusion 

I/O Card area intrusion 

Processor area intrusion 

LAN Leash Lost (system is unplugged from LAN) 
The Event Data 2 field can be used to identify which network 
controller the leash was lost on where 00h corresponds to the first 
(or only) network controller. 

Unauthorized dock 

FAN area intrusion (supports detection of hot plug fan tampering) 

Secure Mode (Front Panel Lockout) Violation attempt 

Pre-boot Password Violation - user password 

Pre-boot Password Violation attempt - setup password 


Pre-boot Password Violation - network boot password 
Other pre-boot Password Violation 
Out-of-band Access Password Violation 


IERR 

Thermal Trip 

FRB1/BIST failure 

FRB2/Hang in POST failure (used hang is believed to be due or 
related to a processor failure. Use System Firmware Progress 
sensor for other BIOS hangs.) 

FRB3/Processor Startup/lnitialization failure (CPU didn't start) 

Configuration Error 

SM BIOS ‘Uncorrectable CPU-complex Error’ 

Processor Presence detected 

Processor disabled 

Terminator Presence Detected 

Processor Automatically Throttled (processor throttling triggered by a 

hardware-based mechanism operating independent from system 

software, such as automatic thermal throttling or throttling to limit 

power consumption.) 

Machine Check Exception (Uncorrectable) 

Correctable Machine Check Error 
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Sensor Sensor- 
Type specific 
Sensor Type Code Offset 


Power Supply (also used 08h Presence detected 
for power converters Power Supply Failure detected 
[e.g. DC-to-DC Predictive Failure 
converters] and VRMs Power Supply input lost (AC/DC)?! 
oa Power Supply input lost or out-of-range 
Power Supply input out-of-range, but present 
Configuration error. The Event Data 3 field provides a more detailed 
definition of the error: 
7:4 = Reserved for future definition, set to 0000b 
3:0 = Error Type, one of 
Oh = Vendor mismatch, for power supplies that include this 
status. (Typically, the system OEM defines the vendor 
compatibility criteria that drives this status). 
1h = Revision mismatch, for power supplies that include this 
status. (Typically, the system OEM defines the vendor 
revision compatibility that drives this status). 
2h = Processor missing. For processor power supplies (typically 
DC-to-DC converters or VRMs), there's usually a one-to- 
one relationship between the supply and the CPU. This 
offset can indicate the situation where the power supply is 
present but the processor is not. This offset can be used for 
reporting that as an unexpected or unsupported condition. 
3h = Power Supply rating mismatch. The power rating of the 
supply does not match the system's requirements. 
4h = Voltage rating mismatch. The voltage rating of the supply 
does not match the system's requirements. 
Others = Reserved for future definition 
Power Supply Inactive (in standby state). Power supply is ina 
standby state where its main outputs have been automatically 
deactivated because the load is being supplied by one or more other 
power supplies. 
Power Unit Power Off / Power Down 
Power Cycle 
240VA Power Down 
Interlock Power Down 
AC lost / Power input lost (The power source for the power unit was 
lost) 
Soft Power Control Failure (unit did not respond to request to turn on) 
Power Unit Failure detected 
Predictive Failure 


Cooling Device 

Other Units-based OBh - - 
Sensor (per units given in 

SDR) 
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Sensor Sensor- 
Type specific 
| Sensor Type | Code | Offset | Event — —  ———  )))))))”*”fñk ze Offset 


[Memory J] OGh | 00h Į CorrectableECC/othercorrectablememoryerror | 
Uncorrectable ECC / other uncorrectable memory error 
Parity 
Memory Scrub Failed (stuck bit) 
Memory Device Disabled 
Correctable ECC / other correctable memory error logging limit 
reached 
Presence detected. Indicates presence of entity associated with the 
sensor. Typically the entity will be a ‘memory module’ or other entity 
representing a physically replaceable unit of memory. 
Configuration error. Indicates a memory configuration error for the 
entity associated with the sensor. This can include when a given 
implementation of the entity is not supported by the system (e.g., 
when the particular size of the memory module is unsupported) or 
that the entity is part of an unsupported memory configuration (e.g. 
the configuration is not supported because the memory module 
doesn’t match other memory modules). 
Spare. Indicates entity associated with the sensor represents a 
‘spare’ unit of memory. 
The Event Data 3 field can be used to provide an event extension 
code, with the following definition: 
Event Data 3 
[7:0] - Memory module/device (e.g. DIMM/SIMM/RIMM) 
identification, relative to the entity that the sensor is 
associated with (if SDR provided for this sensor). 
Memory Automatically Throttled. (memory throttling triggered by a 
hardware-based mechanism operating independent from system 
software, such as automatic thermal throttling or throttling to limit 
power consumption.) 
Critical Overtemperature. Memory device has entered a critical 
overtemperature state, exceeding specified operating conditions. 
Memory devices in this state may produce errors or become 
inaccessible. 


Drive Slot (Bay) Drive Presence 

Drive Fault 

Predictive Failure 

Hot Spare 

Consistency Check / Parity Check in progress 

In Critical Array 

In Failed Array 

Rebuild/Remap in progress 

Rebuild/Remap Aborted (was not completed normally) 
POST Memory Resize OEh - - 
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Sensor Sensor- 
Type specific 
Sensor Type Code Offset 


System Firmware OFh 00h System Firmware Error (POST Error) 
Progress (formerly POST The Event Data 2 field can be used to provide an event extension 
Error) code, with the following definition: 


Event Data 2 


00h Unspecified. 
01h No system memory is physically installed in the system. 
02h No usable system memory, all installed memory has 
experienced an unrecoverable failure. 
03h Unrecoverable hard-disk/ATAPI/IDE device failure. 
04h Unrecoverable system-board failure. 
05h Unrecoverable diskette subsystem failure. 
06h Unrecoverable hard-disk controller failure. 
07h Unrecoverable PS/2 or USB keyboard failure. 
08h Removable boot media not found 
09h Unrecoverable video controller failure 
OAh No video device detected 
OBh Firmware (BIOS) ROM corruption detected 
OCh CPU voltage mismatch (processors that share same supply 
have mismatched voltage requirements) 
ODh CPU speed matching failure 
OEh to FFh reserved 
Oth System Firmware Hang (uses same Event Data 2 definition as 
following System Firmware Progress offset) 
02h System Firmware Progress 
The Event Data 2 field can be used to provide an event extension 
code, with the following definition: 


Event Data 2 


00h Unspecified. 

Oih Memory initialization. 

02h Hard-disk initialization 

03h Secondary processor(s) initialization 

04h User authentication 

05h User-initiated system setup 

06h USB resource configuration 

07h PCI resource configuration 

08h Option ROM initialization 

09h Video initialization 

OAh Cache initialization 

0Bh SM Bus initialization 

OCh Keyboard controller initialization 

ODh Embedded controller/management controller initialization 
OEh Docking station attachment 

OFh Enabling docking station 

10h Docking station ejection 

11h Disabling docking station 

12h Calling operating system wake-up vector 
13h Starting operating system boot process, e.g. calling Int 19h 
14h Baseboard or motherboard initialization 
15h reserved 

16h Floppy initialization 

17h Keyboard test 

18h Pointing device test 

19h Primary processor initialization 

1Ah to FFh reserved 
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Sensor Sensor- 
Type specific 
Sensor Type Code Offset 


Event Logging Disabled 10h Correctable Memory Error Logging Disabled 

Event Data 2 

[7:0] - Memory module/device (e.g. DIMM/SIMM/RIMM) 
identification, relative to the entity that the sensor is 
associated with (if SDR provided for this sensor). 

Event ‘Type’ Logging Disabled. Event Logging is disabled for 
following event/reading type and offset has been disabled. 

Event Data 2 

Event/Reading Type Code 

Event Data 3 

[7:6] - reserved. Write as OOb. 

[5]- 1b = logging has been disabled for all events of given type 

[4]- 1b = assertion event, Ob = deassertion event 

[3:0] - Event Offset 

Log Area Reset/Cleared 

All Event Logging Disabled 

SEL Full. If this is used to generate an event, it is recommended 
that this be generated so that this will be logged as the last entry in 
the SEL. If the SEL is very small, an implementation can elect to 
generate this event after the last entry has been placed in the SEL to 
save space. In this case, this event itself would not get logged, but 
could still trigger actions such as an alert via PEF. Note that an 
application can always use the Get SEL Info command to determine 
whether the SEL is full or not. Since Get SEL Info is a mandatory 
command, this provides a cross-platform way to get that status. 

SEL Almost Full. H Event Data 3 is not provided, then by default this 
event represents the SEL has reached a point of being 75% or more 
full. For example, if the SEL supports 215 entries, the 75% value 
would be 161.25 entries. Therefore, the event would be generated on 
the 162nd entry. Note that if this event itself is logged, it would be 
logged as the 163rd entry. 

Event Data 3 

Contains hex value from 0 to 100 decimal (00h to 64h) 

representing the % of which the SEL is filled at the time the event 

was generated: 00h is 0% full (SEL is empty), 64h is 100% full, etc. 
Correctable Machine Check Error Logging Disabled 
If the following field is not provided, then this event indicates that 
Correctable Machine Check error logging has been disabled for all 
Processor sensors. 

Event Data 2 

Event Data 2 may be optionally used to return an Entity Instance 

or a vendor selected processor number that identifies the 

processor associated with this event. 

[7:0] - Instance ID number of the (processor) Entity that the sensor 
is associated with (if SDR provided for this sensor), or a 
vendor selected logical processor number if no SDR. 

Event Data 3 

If Event Data 2 is provided then Event Data 3 may be optionally 

used to indicate whether Event Data 2 is being used to hold an 

Entity Instance number or a vendor-specific processor number. If 

Event Data 2 is provided by Event Data 3 is not, then Event Data 2 

is assumed to hold an Entity Instance number. 

[7]- Ob = Entity Instance number 
1b = Vendor-specific processor number 

[6:0] - reserved 

Watchdog 1 11h This sensor is provided to support IPMI v0.9 to v1.0 transition. This is 
deprecated in IPMI v1.5. See sensor 23h for recommended definition 
of Watchdog sensor for new v1.0 and for IPMI v1.5 implementations. 


00h BIOS Watchdog Reset 

Oth OS Watchdog Reset 

02h OS Watchdog Shut Down 
03h OS Watchdog Power Down 
04h OS Watchdog Power Cycle 
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Sensor Sensor- 
Type specific 
| Sensor Type | Code | Offset | Event O )))))))”_”*”ñk 


e ff — I oh I OS Watchdog NMI / Diagnostic Interrupt. Al 
OS Watchdog Expired, status only 
OS Watchdog pre-timeout Interrupt, non-NMI 
System Event System Reconfigured 
OEM System Boot Event 
Undetermined system hardware failure 
(this event would typically require system-specific diagnostics to 
determine FRU / failure type) 
Entry added to Auxiliary Log 
(see 31.12, Get Auxiliary Log Status Command and 31.13, Set 
Auxiliary Log Status Command, for more information) 
Event Data 2 
[7:4] - Log Entry Action 
Oh= entry added 
1h= entry added because event did not be map to standard 
IPMI event 
2h= entry added along with one or more corresponding SEL 
entries 
3h = log cleared 
4h = log disabled 
5h = log enabled 
all other = reserved 
[3:0] - Log Type 
Oh = MCA Log 
ih= OEM1 
2h= OEM2 
all other = reserved 
PEF Action 
Event Data 2 
The following bits reflect the PEF Actions that are about to be 
taken after the event filters have been matched. The event is 
captured before the actions are taken. 
[7:6]- reserved 
1b = Diagnostic Interrupt (NMI) 
1b = OEM action 
1b = power cycle 
1b = reset 
1b = power off 
1b = Alert 
Timestamp Clock Synch. 
This event can be used to record when changes are made to the 
timestamp clock(s) so that relative time differences between SEL 
entries can be determined. See note I". 
Event Data 2 
[7] - first/second 
Ob = event is first of pair. 
1b = event is second of pair. 
[6:4] - reserved 
[3:0] - Timestamp Clock Type 
Oh = SEL Timestamp Clock updated. (Also used when both 
SEL and SDR Timestamp clocks are linked together.) 
ih = SDR Timestamp Clock updated. 
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Sensor Type 


Critical Interrupt 


Button / Switch 


Module / Board 


Microcontroller / 
Coprocessor 


Add-in Card 


Chip Set 


Sensor 
Type 
Code 


13h 


14h 


Sensor- 
specific 
Offset 


Intelligent Platform Management Interface Specification 


Front Panel NMI / Diagnostic Interrupt 

Bus Timeout 

VO channel check NMI 

Software NMI 

PCI PERR 

PCI SERR 

EISA Fail Safe Timeout 

Bus Correctable Error 

Bus Uncorrectable Error 

Fatal NMI (port 61h, bit 7) 

Bus Fatal Error 

Bus Degraded (bus operating in a degraded performance state) 
Power Button pressed 

Sleep Button pressed 

Reset Button pressed 

FRU latch open (Switch indicating FRU latch is in ‘unlatched’ position 
and FRU is mechanically removable) 

FRU service request button (1 = pressed, service, e.g. 
removal/replacement, requested) 


Soft Power Control Failure (chip set did not respond to BMC request 
to change system power state). This offset is similar to offset 05h for 
a power unit, except that the power unit event is only related to a 
failure to power up, while this event corresponds to any system 
power state change directly requested via the BMC. 


Event Data 2 
The Event Data 2 field for this command can be used to provide 
additional information on the type of failure with the following 
definition: 
Requested power state 
00h = SO / GO “working” 
Oth = S1 “sleeping with system h/w & processor context 
maintained” 
02h = S2 “sleeping, processor context lost” 
03h = S3 “sleeping, processor & h/w context lost, memory 
retained.” 
04h = S4 “non-volatile sleep / suspend-to disk” 
05h = S5 / G2 "soft-off” 
06h = S4/S5 soft-off, particular S4 / S5 state cannot be 
determined 
07h = G3 / Mechanical Off 
08h = Sleeping in an S1, S2, or S3 states (used when particular 
S1, S2, S3 state cannot be determined) 
09h = G1 sleeping (S1-S4 state cannot be determined) 
OAh = S5 entered by override 
OBh = Legacy ON state 
OCh = Legacy OFF state 
ODh = reserved 


Event Data 3 
The Event Data 3 field for this command can be used to provide 
additional information on the type of failure with the following 
definition: 

Power state at time of request 

00h = SO / GO “working” 

Oth = S1 “sleeping with system h/w & processor context 

maintained” 
02h = S2 “sleeping, processor context lost” 
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Sensor Sensor- 
Type specific 
| Sensor Type | Code | Offset | Event ñk 


03h = S3“ ‘sleeping, processor & h/w context lost, memory 
retained.” 

04h = S4 “non-volatile sleep / suspend-to disk” 

05h = S5 / G2 "soft-off” 

06h = S4/S5 soft-off, particular S4 / S5 state cannot be 
determined 

07h = G3/ Mechanical Off 

08h = Sleeping in an S1, S2, or S3 states (used when particular 
S1, S2, S3 state cannot be determined) 

09h = G1 sleeping (S1-S4 state cannot be determined) 

OAh = S5 entered by override 

OBh = Legacy ON state 

OCh = Legacy OFF state 

ODh = unknown 

Thermal Trip 
cl 


Other FRU Ee — 


Cable/lnterconnect is connected 
Oih Configuration Error - Incorrect cable connected / Incorrect 
interconnection 
| Terminator | Ch OP 


System Boot / Restart Initiated by power up (this would typically be generated by BIOS/EFI) 
Initiated 
Initiated by hard reset (this would typically be generated by 
BIOS/EFI) 
Initiated by warm reset (this would typically be generated by 
BIOS/EFI) 
User requested PXE boot 


Automatic boot to diagnostic 
OS / run-time software initiated hard reset 


OS / run-time software initiated warm reset 
System Restart (Intended to be used with Event Data 2 and or 3 as 
follows:) 
Event Data 2 
[7:4] - reserved 
[3:0] - restart cause per Get System Restart Cause command. 
Event Data 3 
Channel number used to deliver command that generated restart, 
per Get System Restart Cause command. 
Boot Error No bootable media 
Non-bootable diskette left in drive 
PXE Server not found 
Invalid boot sector 
Timeout waiting for user selection of boot source 
Base OS Boot / A: boot completed 
Installation Status C: boot completed 
PXE boot completed 
Diagnostic boot completed 
CD-ROM boot completed 
ROM boot completed 
boot completed - boot device not specified 
Base OS/Hypervisor Installation started (Reflects Base Operating 
System / Hypervisor Installation, not installing/provisioning a VM.) 
Base OS/Hypervisor Installation completed 
Base OS/Hypervisor Installation aborted 
Base OS/Hypervisor Installation failed 


OS Stop / Shutdown 20h 00h Critical stop during OS load / initialization. Unexpected error during 
system startup. Stopped waiting for input or power cycle/reset. 
Oih Run-time Critical Stop (a.k.a. ‘core dump’, ‘blue screen’) 
02h OS Graceful Stop (system powered up, but normal OS operation has 


shut down and system is awaiting reset pushbutton, power-cycle or 
other external input) 
03h OS Graceful Shutdown (system graceful power down by OS) 
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Sensor Sensor- 
Type specific 
Sensor Type Code Offset 
04 


oft Shutdown initiated by PEF 
Agent Not Responding. Graceful shutdown request to agent via BMC 
did not occur due to missing or malfunctioning local agent. 
Slot / Connector Fault Status asserted 

Identify Status asserted 

Slot / Connector Device installed/attached 
[This can include dock events] 

Slot / Connector Ready for Device Installation - Typically, this means 
that the slot power is off. The Ready for Installation, Ready for 
Removal, and Slot Power states can transition together, 
depending on the slot implementation. 

Slot/Connector Ready for Device Removal 

Slot Power is Off 

Slot / Connector Device Removal Request - This is typically 
connected to a switch that becomes asserted to request removal 
of the device) 

Interlock asserted - This is typically connected to a switch that 
mechanically enables/disables power to the slot, or locks the slot 
in the ‘Ready for Installation / Ready for Removal states’ - 
depending on the slot implementation. The asserted state 
indicates that the lock-out is active. 

Slot is Disabled 

Slot holds spare device 


The Event Data 2 & 3 fields can be used to provide an event 
extension code, with the following definition: 
Event Data 2 
7 reserved 
6:0 Slot/Connector Type 
0 PCI 
Drive Array 
External Peripheral Connector 
Docking 
other standard internal expansion slot 
slot associated with entity specified by Entity ID for sensor 
AdvancedTCA 
DIMM/memory device 
FAN 
PCI Express™ 
10 SCSI (parallel) 
11 SATA / SAS 
all other = reserved 
Event Data 3 
7:0 Slot/Connector Number 
System ACPI Power SO / GO “working” 
State S1 “sleeping with system h/w & processor context maintained” 
S2 “sleeping, processor context lost” 
S3 “sleeping, processor & h/w context lost, memory retained.” 
S4 “non-volatile sleep / suspend-to disk” 
S5 / G2 "soft-off” 
S4 / 55 soft-off, particular S4 / S5 state cannot be determined 
G3 / Mechanical Off 
Sleeping in an S1, S2, or S3 states (used when particular S1, S2, S3 
state cannot be determined) 
G1 sleeping (S1-S4 state cannot be determined) 
S5 entered by override 
Legacy ON state 
Legacy OFF state 
Unknown 
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Sensor Sensor- 
Type specific 
| Sensor Type | Code | Offset | Event  — —  ————— _ ))));””*”ñk Code Offset 


Watchdog 2 This sensor is recommended for new IPMI v1.0 and later 
implementations. 
Timer expired, status only (no action, no interrupt) 
Hard Reset 
Power Down 
Power Cycle 
reserved 
Timer interrupt 
The Event Data 2 field for this command can be used to provide an 
event extension code, with the following definition: 
7:4 interrupt type 
= none 
= SMI 
= NMI 
= Messaging Interrupt 
= unspecified 
all other = reserved 
3:0 timer use at expiration: 
= reserved 
= BIOS FRB2 
= BIOS/POST 
= OS Load 
= SMS/OS 
= OEM 
= unspecified 
all other = reserved 


Platform Alert This sensor can be used for returning the state and generating 
events associated with alerts that have been generated by the 
platform mgmt. subsystem 
platform generated page 
platform generated LAN alert 
Platform Event Trap generated, formatted per IPMI PET specification 
platform generated SNMP trap, OEM format 

Entity Presence This sensor type provides a mechanism that allows a management 
controller to direct system management software to ignore a set of 
sensors based on detecting that presence of an entity. This sensor 
type is not typically used for event generation - but to just provide a 
present reading. 

Entity Present. This indicates that the Entity identified by the Entity ID 
for the sensor is present. 

Entity Absent. This indicates that the Entity identified by the Entity ID 
for the sensor is absent. If the entity is absent, system management 
software should consider all sensors associated with that Entity to be 
absent as well - and ignore those sensors. 

Entity Disabled. The Entity is present, but has been disabled. A 
deassertion of this event indicates that the Entity has been enabled. 


“oer ASIC / IC 


Management Subsystem 28h 00h sensor access degraded or unavailable (A sensor that is degraded 

Health will still return valid results, but may be operating with a slower 
response time, or may not detect certain possible states. A sensor 
that is unavailable is not able to return any results (scanning is 
disabled,) 

Oth controller access degraded or unavailable (The ability to access the 
controller has been degraded, or access is unavailable, but the party 
that is doing the monitoring cannot determine which.) 

02h management controller off-line (controller cannot be accessed for 
normal operation because it has been intentionally taken off-line for a 
non-error condition. Note that any commands that are available must 
function according to specification.) 

03h management controller unavailable (controller cannot be accessed 
because of an error condition) 
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Sensor Sensor- 
Type specific 
| Sensor Type | Code | Offset | Event — —  —— —  — ))))))))”*”fñk 


TT 04h ý E Sensor failure (the sensor is known to be in error. It may silbe | 
accessible by ek 

Event Data 2 

The Event Data 2 field for this offset can be used to provide 
additional information on the type of failure with the following 
definition: 

[7:0] - Sensor Number. Number of the failed sensor corresponding to 
event offset 04h or 00h. 

FRU failure 

The Event Data 2 and 3 fields for this offset can be used to provide 
additional information on the type of failure with the following 
definition: 

Event Data 2 

[7] - logical/physical FRU device 
Ob = device is not a logical FRU Device 
1b = device is logical FRU Device (accessed via FRU 
commands to mgmt. controller) 

[6:5] - reserved. 

[4:3] - LUN for Master Write-Read command or FRU Command. 00b 
if device is non-intelligent device directly on IPMB. 

[2:0] - Private bus ID if bus = Private. 000b if device directly on 
IPMB, or device is a logical FRU Device. 

Event Data 3 

For LOGICAL FRU DEVICE (accessed via FRU commands to 
mgmt. controller): 

[7:0] - FRU Device ID within controller that generated the event.FFh 
= reserved. 

For non-intelligent FRU device: 

[7:1] - 7-bit I2C Slave Address of FRU device . This is relative to the 
bus the device is on. For devices on the IPMB, this is the 
slave address of the device on the IPMB. For devices ona 
private bus, this is the slave address of the device on the 
private bus. 

[0] - reserved. 


Battery 00h battery low (predictive failure) 
Oth battery failed 
02h battery presence detected 


Session Audit 00h Session Activated 
01h Session Deactivated 
02h Invalid Username or Password 


An Invalid Username or Password was received during the session 
establishment process. 

03h Invalid password disable. 
A user's access has been disabled due to a series of bad password 
attempts. This offset can be used in conjunction with the Bad 
Password Threshold option. Refer to the LAN or serial/modem 
configuration parameter for Bad Password Threshold’ for more 
information. 
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Sensor Sensor- 
Type specific 
| Sensor Type | Code | Offset | Event  — —  ————  —  )))))))”_”*”ñk 


The Event Data 2 & 3 fields can be used to provide an event 
extension code for the preceding offsets, with the following definition: 
Event Data 2 
7:6 reserved 
5:0 User ID for user that activated session. 
00_0000b = unspecified. 
Event Data 3 
7:6 reserved 
5:4 Deactivation cause 
00b = Session deactivatation cause unspecified. This value 
is also used for Session Activated events. 
01b = Session deactivated by Close Session command 
10b = Session deactivated by timeout 
11b = Session deactivated by configuration change 
3:0 Channel number that session was activated/deactivated over. 
Use channel number that session was activated over if a session 
was closed for an unspecified reason, a timeout, or a configuration 
change. 


Version Change Hardware change detected with associated Entity. Informational. This 
offset does not imply whether the hardware change was successful 
or not. Only that a change occurred. 


01h Firmware or software change detected with associated Entity. 
Informational. Success or failure not implied. 

02h Hardware incompatibility detected with associated Entity. 

03h Firmware or software incompatibility detected with associated Entity. 

04h Entity is of an invalid or unsupported hardware version. 

05h Entity contains an invalid or unsupported firmware or software 
version. 

06h Hardware Change detected with associated Entity was successful. 
(deassertion event means ‘unsuccessful’). 

07h Software or F/W Change detected with associated Entity was 


successful. (deassertion event means ‘unsuccessful’) 
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FRU State 


Sensor 
Type 
Code 


Sensor- 
specific 
Offset 
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Event data 2 can be used for additional event information on the type 
of version change, with the following definition: 
Event Data 2 
7:0 Version change type 
00h unspecified 
01h management controller device ID (change in one or more 
fields from ‘Get Device ID’) 
02h management controller firmware revision 
03h management controller device revision 
04h management controller manufacturer ID 
05h management controller IPMI version 
06h management controller auxiliary firmware ID 
07h management controller firmware boot block 
08h other management controller firmware 
09h system firmware (EFI / BIOS) change 
OAh SMBIOS change 
OBh operating system change 
OCh operating system loader change 
ODh service or diagnostic partition change 
OEh management software agent change 
OFh management software application change 
10h management software middleware change 
11h programmable hardware change (e.g. FPGA) 
12h board/FRU module change (change of a module plugged 
into associated entity) 
13h board/FRU component change (addition or removal of a 
replaceable component on the board/FRU that is not 
tracked as a FRU) 
14h board/FRU replaced with equivalent version 
15h board/FRU replaced with newer version 
16h board/FRU replaced with older version 
17h board/FRU hardware configuration change (e.g. strap, 
jumper, cable change, etc.) 
FRU Not Installed 
FRU Inactive (in standby or ‘hot spare’ state) 
FRU Activation Requested 
FRU Activation In Progress 
FRU Active 
FRU Deactivation Requested 
FRU Deactivation In Progress 
FRU Communication Lost 
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Sensor Sensor- 
Type specific 
| Sensor Type | Code | Offset | Event O ))))))))””*”fñk 


The Event Data 2 field for this command can be used to provide the 

cause of the state change and the previous state: 

7:4 Cause of state change 
Oh = Normal State Change. 
1h = Change Commanded by software external to FRU. 
2h = State Change due to operator changing a Handle 

latch. 
3h = State Change due to operator pressing the hot swap 
push button. 

4h = State Change due to FRU programmatic action. 
5h = Communication Lost. 
6h = Communication Lost due to local failure. 
7h = State Change due to unexpected extraction. 
8h = State Change due to operator intervention/update. 
9h = Unable to compute IPMB address. 
Ah = Unexpected Deactivation. 
Fh = State Change, Cause Unknown. 
All other = reserved 

3:0 Previous state offset value (return offset for same state as 
present state if previous state is unknown) 

All other = reserved. 

Reserved remaini - 
ng 


OEM RESERVED COh- 
FFh 


ig 


2. 


518 


To track the relationship between timestamps, the timestamp change events should be logged in pairs - the first event being 
logged just before the timestamp clock update followed by a second event that is logged after the timestamp clock has been 
updated. This enables software that reads the SEL to be able to determine time relationship between events that were logged 
before the update and those logged afterward. The generation of these events is normally the responsibility of the software that 
changes the timestamp clock. Note that some implementations may queue events prior to their being logged. It is recommended 
that generic software read the SEL to verify that the first event has been recorded with the relative timestamp before setting the 
new timestamp value and generating the second event. 

“Power supply input” refers to AC or DC source inputs to the power supply or power converter. 
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43. Sensor Data Record Formats 


The general Sensor Data Record format consists of three major components, the Record Header, Record ‘Key’ 
fields, and the Record Body. In order to save space, Sensor Data Records are not required for sensors that only 
generate events. In particular, sensors that do not require initialization by the initialization agent, and are not 
expected to be accessed by system management software to obtain present readings, etc. (Generic system 
management software does not access sensors that are not reported via the SDRs). 


RECORD HEADER 
Is the same for all records, consisting of: 


Record ID: A value that’s used for accessing Sensor Data Records. Note that since Record IDs may be 
reassigned, retrievers of a record should use the ‘KEY’ fields to verify that the expected record was 
obtained. 


SDR Version: The version number of the SDR specification. Used in conjunction with Record Type, 
following. 


Record Type: A number representing the type of the record. E.g. Olh = 8-bit Sensor with Thresholds. 
Record Length: Number of bytes of data following the Record Length field. 


RECORD ‘KEY’ FIELDS 


The Record ‘Key’ Fields are a set of fields that together are unique amongst instances of a given record 
type. For example, for ‘sensor’ records, these fields specify the location (e.g. slave address, LUN, and Bus 
ID) and sensor number of the sensor. The Record Key bytes shall be contiguous and follow the Record 
Header. The number of bytes that make up the Record Key field may vary according to record type. 


RECORD BODY 


The remaining Record Type specific information for the particular sensor data record. 
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43.1 SDR Type 01h, Full Sensor Record 


The Full Sensor Record can be used to describe any type of sensor. The Compact sensor record saves space, but 
has limitations in the sensors it can describe. The Full record is defined as a 64-byte record, while the Compact 
record is defined as 48-bytes. Other differences are summarized in the following table: 


Supported in Supported in 
Full Sensor Record? Compact Sensor Record? 
Sensor Capability (type 01h) (type 02h) 


Sensor provides analog readings yes 


Sensor requires threshold value initialization yes 
Sensor requires hysteresis value initialization yes 
Multiple sensors can share record 


* Note: sensors that require unique event or hysteresis configuration cannot share a record. 


A threshold-based sensor is a special-case of a discrete sensor. In the Get Sensor Reading command, a discrete 
sensor returns the present status for all discrete states monitored by the sensor, while a threshold-based sensor 
returns a threshold comparison status. 


Thus, the Discrete Reading Mask field in the SDR for a discrete sensor is used to indicate which possible states 
can be read using a Get Sensor Reading command. While the Upper and Lower Threshold Reading Mask fields 
for a threshold-based sensor indicates which thresholds can be read. 


Table 43-, Full Sensor Record - SDR Type Olh 
| byte | Field Name | size |Description | 


SENSOR RECORD HEADER 
1:2 | Record ID 2 | The Record ID is used by the Sensor Data Repository device for record 
organization and access. It is not related to the sensor ID. 
3 | SDR Version 1 Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. BCD encoded with bits 7:4 holding the Least Significant 
digit of the revision and bits 3:0 holding the Most Significant bits. 


Record Type Record Type Number = 01h, Full Sensor Record 
Record Length Number of remaining record bytes following. 


RECORD KEY BYTES 


Sensor Owner ID 1 | [7:1]- 7-bit DC Slave Address, or 7-bit system software ID! 
[0] - Ob = ID is IPMB Slave Address, 1b = system software ID 


Sensor Owner LUN [7:4] - Channel Number 
The Channel Number can be used to specify access to sensors that are 
located on management controllers that are connected to the BMC via 
channels other than the primary IPMB. (Note: In IPMI v1.5 the ordering of 
bits 7:2 of this byte have changed to support the 4-bit channel number.) 


[3:2] - reserved 

[1:0] - Sensor Owner LUN. LUN in the Sensor Owner that is used to send/receive 
IPMB messages to access the sensor. 00b if system software is Sensor 
Owner. 


Sensor Number 1 Unique number identifying the sensor behind a given slave address and LUN. 
Code FFh reserved. 


RECORD BODY BYTES 


9 | Entity ID 1 Indicates the physical entity that the sensor is monitoring or is otherwise 
associated with the sensor. See Table 43-, Entity ID Codes. 
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| byte | Field Name | size |Description S O 
10 | Entity Instance Ob = treat entity as a physical entity per Entity ID table 

1b = treat entity as a logical container entity. For example, if this bit is set, 

and the Entity ID is ‘Processor’, the container entity would be considered 

to represent a logical ‘Processor Group’ rather than a physical processor. 

This bit is typically used in conjunction with an Entity Association record. 

Instance number for entity. (See section 39.1, System- and Device-relative 

Entity Instance Values for more information) 

00h-5Fh system-relative Entity Instance. The Entity Instance number 
must be unique for each different entity of the same type Entity 
ID in the system. 

60h-7Fh device-relative Entity Instance. The Entity Instance number must 
only be unique relative to the management controller providing 
access to the Entity. 

Sensor Initialization Settable Sensor 1b = Sensor is settable (Support the Set Sensor 
Reading And Event Status command) note: using 
this bit to report settable sensors is optional. l.e. it is 
ok to report a settable sensor as ‘not settable’ in the 
SDR if it is desired to not report this capability to 
s/w) 

Ob = Sensor is not settable 

[6] - Init Scanning 1b = enable scanning (this bit=1 implies that the sensor 
accepts the ‘enable/disable scanning’ bit in the Set 
Sensor Event Enable command). 

[5] - Init Events 1b = enable events (per Sensor Event Message Control 
Support bits in Sensor Capabilities field, and per 
the Event Mask fields, below). 

[4] - Init Thresholds 1b = initialize sensor thresholds (per settable threshold 
mask below). 

[3] - Init Hysteresis 1b = initialize sensor hysteresis (per Sensor Hysteresis 
Support bits in the Sensor Capabilities field, 
below). 

[2] - Init Sensor Type 1b = initialize Sensor Type and Event / Reading Type 
code 

Sensor Default (power up) State 

Reports how this sensor comes up on device power up and hardware/cold reset. 

The Initialization Agent does not use this bit. This bit solely reports to software 

how the sensor comes prior to being initialized by the Initialization Agent. 

[1] - Ob = event generation disabled, 1b = event generation enabled 

[0] - Ob = sensor scanning disabled, 1b = sensor scanning enabled 
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Field Name 


2 | Sensor Capabilities 


1 
1 


3 | Sensor Type 


Event / Reading Type Code 


1 


1 
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[7] - 1b = Ignore sensor if Entity is not present or disabled. 
Ob = don't ignore sensor 


Sensor Auto Re-arm Support 

Indicates whether the sensor requires manual rearming, or automatically rearms 
itself when the event clears. ‘manual’ implies that the get sensor event status and 
rearm sensor events commands are supported 

[6] - Ob = no (manual), 1b = yes (auto) 


Sensor Hysteresis Support 
[5:4]- 00b= No hysteresis, or hysteresis built-in but not specified. 
O1b = hysteresis is readable. 
10b = hysteresis is readable and settable. 
11b = Fixed, unreadable, hysteresis. Hysteresis fields values 
implemented in the sensor. 


Sensor Threshold Access Support 
[3:2] - 00b= no thresholds. 
O1b = thresholds are readable, per Reading Mask, below. 
10b = thresholds are readable and settable per Reading Mask and 
Settable Threshold Mask, respectively. 
11b = Fixed, unreadable, thresholds. Which thresholds are supported is 
reflected by the Reading Mask. The threshold value fields report 
the values that are ‘hard-coded’ in the sensor. 


Sensor Event Message Control Support 
Indicates whether this sensor generates Event Messages, and if so, what type of 
Event Message control is offered. 
[1:0] - OOb = per threshold/discrete-state event enable/disable control (implies 
that entire sensor and global disable are also supported) 
01b = entire sensor only (implies that global disable is also supported) 
10b = global disable only 
11b = no events from sensor 
Code representing the sensor type. From Table 42-, Sensor Type Codes. 
E.g. Temperature, Voltage, Processor, etc. 
Event/Reading Type Code. From Table 42-, Event/Reading Type Code Ranges. 
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Field Name | size |Description | 


15 | Assertion Event Mask / Lower 
16 | Threshold Reading Mask 
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This field reports the assertion event generation or threshold event generation 
capabilities for a discrete or threshold-based sensor, respectively. This field is 
also used by the init agent to enable assertion event generation when the ‘Init 
Events’ bit in the Sensor Capabilities field is set and the Sensor Event Message 
Control Support field indicates that the sensor has ‘per threshold/discrete state’ 
event enable control. 


Assertion Event Mask (for non- threshold-based sensors) 

The Event Mask bytes are a bit mask that specifies support for 15 successive 
events starting with the event specified by Event/Reading Type Code. LS byte 
first. 


[15]- reserved. Write as ‘0’. 
[14:0] - Event offsets 14 through 0, respectively. 
1b = assertion event can be generated by this sensor 


Lower Threshold Reading Mask (for threshold-based sensors) 

Indicates which lower threshold comparison status is returned via the Get Sensor 
Reading command. 

[15] - reserved. Write as Ob 

[14] - 1b = Lower non-recoverable threshold comparison is returned 

[13] - 1b = Lower critical threshold is comparison returned 

[12]- 1b = Lower non-critical threshold is comparison returned 


Threshold Assertion Event Mask (for threshold-based sensors) 

[11]- 1b = assertion event for upper non-recoverable going high supported 
[10]- 1b = assertion event for upper non-recoverable going low supported 
[9] - 1b = assertion event for upper critical going high supported 

[8] - 1b = assertion event for upper critical going low supported 

[7] - 1b = assertion event for upper non-critical going high supported 

[6] - 1b = assertion event for upper non-critical going low supported 

[5] - 1b = assertion event for lower non-recoverable going high supported 
[4] - 1b = assertion event for lower non-recoverable going low supported 
[3] - 1b = assertion event for lower critical going high supported 

[2] - 1b = assertion event for lower critical going low supported 

[1] - 1b = assertion event for lower non-critical going high supported 

[0] - 1b = assertion event for lower non-critical going low supported 


Intelligent Platform Management Interface Specification 


Field Name | size |Description 4 


17 | Deassertion Event Mask / Upper 
18 | Threshold Reading Mask 


19 | Discrete Reading Mask / Settable 
20 | Threshold Mask, Readable 
Threshold Mask 


Deassertion Event Mask (for non- threshold-based sensors) 
The Event Mask bytes are a bit mask that specifies support for 15 successive 
events starting with the event specified by Event/Reading Type Code. LS byte 
first. 
[15] - reserved. Write as Ob 
[14:0] - Event offsets 14 through 0, respectively. 

1b = assertion event can be generated for this state. 


Upper Threshold Reading Mask (for threshold-based sensors) 

Indicates which upper threshold comparison status is returned via the Get Sensor 
Reading command. 

[15] - reserved. Write as Ob 

[14] - 1b = Upper non-recoverable threshold comparison is returned 

[13] - 1b = Upper critical threshold is comparison returned 

[12]- 1b = Upper non-critical threshold is comparison returned 


Threshold Deassertion Event Mask 
[11]- 1b = deassertion event for upper non-recoverable going high supported 
[10]- 1b = deassertion event for upper non-recoverable going low supported 
[9] - 1b = deassertion event for upper critical going high supported 
[8] - 1b = deassertion event for upper critical going low supported 
[7] - 1b = deassertion event for upper non-critical going high supported 
[6] - 1b = deassertion event for upper non-critical going low supported 
[5] - 1b = deassertion event for lower non-recoverable going high supported 
[4] - 1b = deassertion event for lower non-recoverable going low supported 
[3] - 1b = deassertion event for lower critical going high supported 
[2] - 1b = deassertion event for lower critical going low supported 
[1] - 1b = deassertion event for lower non-critical going high supported 
[0] - 1b = deassertion event for lower non-critical going low supported 
Reading Mask (for non- threshold based sensors) 
Indicates what discrete readings can be returned by this sensor, or, for threshold 
based sensors, this indicates which thresholds are settable and which are 
readable. The Reading Mask bytes are a bit mask that specifies support for 15 
successive states starting with the value from Table 36-1, Event/Reading Type 
Code Ranges. LS byte first. 
[15] - reserved. Write as Ob 
[14:0] - state bits 0 through 14. 

1b = discrete state can be returned by this sensor. 


Settable Threshold Mask (for threshold-based sensors) 

Indicates which thresholds are settable via the Set Sensor Thresholds. This mask 
also indicates which threshold values will be initialized if the ‘Init Events’ bit is set. 
LS byte first. 

[15:14] - reserved. Write as 00b. 

[13] - 1b = Upper non-recoverable threshold is settable 

[12]- 1b = Upper critical threshold is settable 

[11] - 1b = Upper non-critical threshold is settable 

[10] - 1b = Lower non-recoverable threshold is settable 

[9] - 1b = Lower critical threshold is settable 

[8] - 1b = Lower non-critical threshold is settable 


Readable Threshold Mask (for threshold-based sensors) 

Indicates which thresholds are readable via the Get Sensor Thresholds 
command. 

[7:6] - reserved. Write as 00b. 

[5] - 1b = Upper non-recoverable threshold is readable 

[4] - 1b = Upper critical threshold is readable 

[3] - 1b = Upper non-critical threshold is readable 

[2] - 1b = Lower non-recoverable threshold is readable 

[1] - 1b = Lower critical threshold is readable 

[0] - 1b = Lower non-critical threshold is readable 
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Field Name | size |Description | 


21 | Sensor Units 1 1 [7:6] - Analog (numeric) Data Format** 
00b = unsigned 
01b = 1’s complement (signed) 
10b = 2’s complement (signed) 
11b = Does not return analog (numeric) reading 
[5:3] - Rate unit 
000b = none 
001b = per uS 
010b = per ms 
011b=pers 
100b = per minute 
101b = per hour 
110b = per day 
111b = reserved 
[2:1] - Modifier unit 
00b = none 
01b = Basic Unit / Modifier Unit 
10b = Basic Unit * Modifier Unit 
11b = reserved 
[0] - Percentage Ob = no, 1b = yes 
** Specifies threshold and ‘analog’ reading, if ‘analog’ reading provided. If neither 
thresholds nor analog reading are provided, this field should be written as OOh. 


Sensor Units 2 - Base Unit [7:0] - Units Type code: See Table 43-, Sensor Unit Type Codes. 
Sensor Units 3 - Modifier Unit [7:0] - Units Type code, 00h if unused. 


24 | Linearization 1 reserved 
i enum (linear, In, log10, log2, e, exp10, exp2, 1/x, sqr(x), cube(x), sqrt(x), 
cube" (x) ) - 70h = non-linear. 71h-7Fh = non-linear, OEM defined. 


[7:0]- M: LS 8 bits [2’s complement, signed, 10 bit ‘M’ value] - 


26 |M, Tolerance 1 E M: MS 2 bits 
i Tolerance: 6 bits, unsigned (Tolerance in +/- % raw counts) 


(271B [4 JO B: LS 8 bits [2's complement, signed, 10-bit ‘B’ value]- 


28 |B, Accuracy 1 B: MS 2 bits 
Unsigned, 10-bit Basic Sensor Accuracy in 1/100 percent scaled up by unsigned 
Accuracy exponent: 
[5:0] - Accuracy: LS 6 bits 
1 


29 | Accuracy, Accuracy exp, Sensor Accuracy: MS 4 bits 
Direction i Accuracy exp: 2 bits, unsigned 

Sensor Direction. Indicates whether the sensor is monitoring an input or 
output relative to the given Entity. E.g. if the sensor is monitoring a 
current, this can be used to specify whether it is an input voltage or an 
output voltage. 
00b = unspecified / not applicable 
O1b = input 
10b = output 
11b = reserved 
R (result) exponent 4 bits, 2’s complement, signed 
B exponent 4 bits, 2’s complement, signed 
reserved 
normal min specified 1b = yes, Ob = normal min field unspecified 
normal max specified 1b = yes, Ob = normal max field unspecified 
nominal reading specified 1b = yes, Ob = nominal reading field 
unspecified 


1 Given as a raw value. Must be converted to units-based value using the ‘y=Mx+B’ 
formula. 1's or 2’s complement signed or unsigned per flag bits in Sensor Units 1. 
33 | Normal Maximum Given as a raw value. Must be converted to units-based value using the ‘y=Mx+B’ 
formula. 1’s or 2’s complement signed or unsigned per ‘signed’ bit in Sensor Units 

1: 


34 | Normal Minimum 1 Given as a raw value. Must be converted to units-based value using the ‘y=Mx+B’ 
formula. Signed or unsigned per ‘signed’ bit in Sensor Units 1. 
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byte | Field Name 


35 | Sensor Maximum Reading 


Given as a raw value. Must be converted to units-based value based using the 
y=Mx+B formula. Signed or unsigned per ‘signed’ bit in sensor flags. Normally 
‘FFh’ for an 8-bit unsigned sensor, but can be a lesser value if the sensor has a 
restricted range. If max. reading cannot be pre-specified this value should be set 
to max value, based on data format, (e.g. FFh for an unsigned sensor, 7Fh for 2’s 
complement, etc.) 

Given as a raw value. Must be converted to units-based value using the ‘y=Mx+B’ 
formula. Signed or unsigned per ‘signed’ bit in sensor flags. If min. reading 
cannot be pre-specified this value should be set to min value, based on data 
format, (e.g. OOh for an unsigned sensor, 80h for 2’s complement, etc.) 

Use of this field is based on Settable Threshold Mask. If the corresponding bit is 
set in the mask byte and the ‘Init Sensor Thresholds’ bit is also set, then this 
value will be used for initializing the sensor threshold. Otherwise, this value 
should be ignored. The thresholds are given as raw values that must be 
converted to units-based values using the ‘y=Mx+B’ formula. 


Upper critical Threshold Use of this field is based on Settable Threshold Mask, above 
9 | Upper non-critical Threshold Use of this field is based on Settable Threshold Mask, above 
Lower non-recoverable Threshold 1 Use of this field is based on Settable Threshold Mask, above 


g 


36 | Sensor Minimum Reading 


37 | Upper non-recoverable Threshold 


Co 


CH 


Lower critical Threshold Use of this field is based on Settable Threshold Mask, above 
42 | Lower non-critical Threshold Use of this field is based on Settable Threshold Mask, above 


43 | Positive-going Threshold Positive hysteresis is defined as the unsigned number of counts that are 
Hysteresis value subtracted from the raw threshold values to create the ‘re-arm’ point for all 
positive-going thresholds on the sensor. 0 indicates that there is no hysteresis on 
positive-going thresholds for this sensor. Hysteresis values are given as raw 
counts. That is, to find the degree of hysteresis in units, the value must be 
converted using the ‘y=Mx+B’ formula. 

Negative hysteresis is defined as the unsigned number of counts that are added 
to the raw threshold value to create the ‘re-arm’ point for all negative-going 
thresholds on the sensor. 0 indicates that there is no hysteresis on negative-going 
thresholds for this sensor. 


reserved. Write as 00h 
reserved. Write as 00h 
Reserved for OEM use 


Sensor ‘ID’ String Type/Length Code, per Section 43.15, Type/Length Byte 
Format. 


Sensor ID String bytes. Only present if non-zero length in Type/Length field. 
16 bytes, maximum. Note: the SDR can be implemented as a fixed length record. 
Bytes beyond the ID string bytes are unspecified and should be ignored. 


— 


44 | Negative-going Threshold 
Hysteresis value 


= 


45 | reserved 


6 [reserved i O 
OEM LL 
8 


48 | ID String Type/Length Code 


A 


i 
i 
| 45 | 
| 46 | 
| 47 | 


ID String Bytes 


+» 


Notes: 
1. Resolution, as used in the DMI Systems Standard Groups ‘probes’ groups, can be obtained from the “m” factor in the 
'y=mx+b" reading conversion. 
2.  7-bit PC Slave Address field. By convention, we normally designate an |?C slave address as an eight-bit number with the 
least-significant bit always 0. E.g. 20h = 00100000b. The 7-bit Slave Address field holds the most-significant 7 bits of this 
value. E.g. 0010000b. 
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43.2 SDR Type 02h, Compact Sensor Record 


The Full Sensor Record can be used to describe any type of sensor. The Compact sensor record saves space, but 
has limitations in the sensors it can describe. The Full record is defined as a 64-byte record, while the Compact 
record is defined as 48-bytes. See previous section for a description of other differences between the Full Sensor 
Record and the Compact Sensor Record. 


Table 43-, Compact Sensor Record - SDR Type 02h 
[byte | Field Name | size | Description N] 


SENSOR RECORD HEADER 
organization and access. lt is not related to the sensor ID. 
3 | SDR Version 1 Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. BCD encoded with bits 7:4 holding the Least Significant 
digit of the revision and bits 3:0 holding the Most Significant bits. 


Record Type Record Type Number = 02h, Compact Sensor Record 
Record Length Number of remaining record bytes following. 


RECORD KEY BYTES 


Sensor Owner ID 1. | [7:1] - 7-bit IPC Slave Address, or 7-bit system software ID" 
[0] - Ob = ID is IPMB Slave Address, 1b = system software ID 


Sensor Owner LUN Channel Number 


The Channel Number can be used to specify access to sensors that are 
located on management controllers that are connected to the BMC via 
channels other than the primary IPMB. (Note: In IPMI v1.5 the ordering of 
bits 7:2 of this byte have changed to support the 4-bit channel number) 


FRU Inventory Device Owner LUN. LUN for Write/Read FRU commands to 
access FRU information. 00b otherwise. 


Sensor Owner LUN. LUN in the Sensor Owner that is used to send/receive 
IPMB messages to access the sensor. 00b if system software is Sensor 
Owner. 


Sensor Number 1 Unique number identifying the sensor behind the given slave address and LUN. 
Code FFh reserved. 


RECORD BODY BYTES 


Fer Indicates the physical entity that the sensor is monitoring or is otherwise 
associated. See Table 43-, Entity ID Codes. 
10 | Entity Instance [7]- Ob = treat entity as a physical entity per Entity ID table 
1b = treat entity as a logical container entity. For example, if this bit is set, 
and the Entity ID is ‘Processor’, the container entity would be 
considered to represent a logical ‘Processor Group’ rather than a 
physical processor. This bit is typically used in conjunction with an 
Entity Association record. 
[6:0] - Instance number for entity. (See section 39.1, System- and Device-relative 
Entity Instance Values for more information) 
OOh-SFh system-relative Entity Instance. The Entity Instance number 
must be unique for each different entity of the same type Entity 
ID in the system. 
60h-7Fh device-relative Entity Instance. The Entity Instance number must 
only be unique relative to the management controller providing 
access to the Entity. 
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[5] - Init Events 1b = enable events (per Sensor Event Message Control 
[3] - Init Hysteresis 1b = initialize sensor hysteresis (per Sensor Hysteresis 


Field Name 
Support bits in Sensor Capabilities field, and per 
Support bits in the Sensor Capabilities field, 


11 | Sensor Initialization [7] - Settable Sensor 1b = Sensor is settable (Support the Set Sensor 
Reading And Event Status command) note: using 
this bit to report settable sensors is optional. |.e. it is 
ok to report a settable sensor as ‘not settable’ in the 
SDR if it is desired to not report this capability to 
s/w) 

Ob = Sensor is not settable 
[ Init Scanning 1b = enable scanning (this bit=1b implies that the 
sensor accepts the ‘enable/disable scanning’ bit in 
the Event Mask fields, below.) 
below). 


the Set Sensor Event Enable command). 
[4]- reserved. Write as Ob. 
[2] - Init Sensor Type 1b = initialize Sensor Type and Event / Reading Type 
code 
Sensor Default (power up) State 
Reports how this sensor comes up on device power up and hardware/cold reset. 
The Initialization Agent does not use this bit. This bit solely reports to software 
how the sensor comes prior to being initialized by the Initialization Agent. 
[1]- Ob = event generation disabled, 1b = event generation enabled 
[0] - 0b = sensor scanning disabled, 1b = sensor scanning enabled 
12 | Sensor Capabilities [7]- 1b = ignore sensor if Entity is not present or disabled. 
Ob = don't ignore sensor. 


Sensor Auto Re-arm Support 

Indicates whether the sensor requires manual rearming, or automatically rearms 
itself when the event clears. ‘manual’ implies that the get sensor event 
status and rearm sensor events commands are supported 

[6]- Ob = no (manual), 1b = yes (auto) 


Sensor Hysteresis Support 
[5:4] - 00b = No hysteresis, or hysteresis built-in but not specified. 
01b = hysteresis is readable. 
10b = hysteresis is readable and settable. 
11b= Fixed, unreadable, hysteresis. Hysteresis fields values 
implemented in the sensor. 


Sensor Threshold Access Support 
[3:2] - 00b = no thresholds. 
01b = thresholds are readable, per Reading Mask, below. 
10b = reserved 
11b= Fixed, unreadable, thresholds. Which thresholds are supported is 
reflected by the Reading Mask. The threshold value fields report 
the values that are ‘hard-coded’ in the sensor. 


Sensor Event Message Control Support 

Indicates whether this sensor generates Event Messages, and if so, what type of 
Event Message control is offered. 

[1:0] - 00b = per threshold/discrete-state event enable/disable control (implies 

that entire sensor and global disable are also supported) 

01b = entire sensor only (implies that global disable is also supported) 
10b = global disable only 
11b = no events from sensor 


13 | Sensor Type Code representing the sensor type. From the Table 42-, Sensor Type Codes. 
E.g. Temperature, Voltage, Processor, etc. 
Event / Reading Type Code 1 Event/Reading Type Code. From the Table 42-, Event/Reading Type Code 
Ranges. 
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Field Name site [Description EE 


15 | Assertion Event Mask / Lower 
16 | Threshold Reading Mask 
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This field reports the assertion event generation or threshold event generation 
capabilities for a discrete or threshold-based sensor, respectively. This field is 
also used by the init agent to enable assertion event generation when the ‘Init 
Events’ bit in the Sensor Capabilities field is set and the Sensor Event Message 
Control Support field indicates that the sensor has ‘per threshold/discrete state’ 
event enable control. 


Assertion Event Mask (for non- threshold-based sensors) 
The Event Mask bytes are a bit mask that specifies support for 15 successive 
events starting with the event specified by Event/Reading Type Code. LS byte 
first. 
[15]- reserved. Write as Ob. 
[14:0] - Event offsets 14 through 0, respectively. 

1b = assertion event can be generated by this sensor 


Lower Threshold Reading Mask (for threshold-based sensors) 

Indicates which lower threshold comparison status is returned via the Get Sensor 
Reading command. 

[15] - reserved. Write as Ob 

[14] - Lower non-recoverable threshold comparison is returned 

[13] - Lower critical threshold is comparison returned 

[12] - Lower non-critical threshold is comparison returned 


Threshold Assertion Event Mask (for threshold-based sensors) 


[11]- 1b = assertion event for upper non-recoverable going high supported 
[10] - 1b = assertion event for upper non-recoverable going low supported 
[9]- 1b = assertion event for upper critical going high supported 

[8]- 1b = assertion event for upper critical going low supported 

[7]- 1b = assertion event for upper non-critical going high supported 

[6]- 1b = assertion event for upper non-critical going low supported 

[5]- 1b = assertion event for lower non-recoverable going high supported 
[4]- 1b = assertion event for lower non-recoverable going low supported 
[3] - 1b = assertion event for lower critical going high supported 

[2]- 1b = assertion event for lower critical going low supported 

[1]- 1b = assertion event for lower non-critical going high supported 

[0]- 1b = assertion event for lower non-critical going low supported 
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Field Name | size |Description | 


17 | Deassertion Event Mask / Upper 
18 | Threshold Reading Mask 


19 | Discrete Reading Mask / Settable 
20 | Threshold Mask, Readable 
Threshold Mask 


Deassertion Event Mask (for non- threshold-based sensors) 
The Event Mask bytes are a bit mask that specifies support for 15 successive 
events starting with the event specified by Event/Reading Type Code. LS byte 
first. 
[15]- reserved. Write as Ob 
[14:0] - Event offsets 14 through 0, respectively. 

1b = assertion event can be generated for this state. 


Upper Threshold Reading Mask (for threshold-based sensors) 
Indicates which upper threshold comparison status is returned via the Get Sensor 
Reading command. 

reserved. Write as Ob 

Upper non-recoverable threshold comparison is returned 

Upper critical threshold is comparison returned 

Upper non-critical threshold is comparison returned 


Threshold Deassertion Event Mask 


[11]- 1b = deassertion event for upper non-recoverable going high supported 
[10]- 1b = deassertion event for upper non-recoverable going low supported 
[9] - 1b = deassertion event for upper critical going high supported 

1b = deassertion event for upper critical going low supported 

1b = deassertion event for upper non-critical going high supported 

1b = deassertion event for upper non-critical going low supported 

1b = deassertion event for lower non-recoverable going high supported 
1b = deassertion event for lower non-recoverable going low supported 
1b = deassertion event for lower critical going high supported 

1b = deassertion event for lower critical going low supported 

1b = deassertion event for lower non-critical going high supported 

1b = deassertion event for lower non-critical going low supported 
Reading Mask (for non- threshold based sensors) 

Indicates what discrete readings can be returned by this sensor, or, for threshold 
based sensors, this indicates which thresholds are settable and which are 
readable. The Reading Mask bytes are a bit mask that specifies support for 15 
successive states starting with the value from Table 36-1, Event/Reading Type 
Code Ranges. LS byte first. 

[15]- reserved. Write as Ob 

[14:0] - state bits 0 through 14. 

1b = discrete state can be returned by this sensor. 


Settable Threshold Mask (for threshold-based sensors) 
Indicates which thresholds are settable via the Set Sensor Thresholds. This mask 
also indicates which threshold values will be initialized if the ‘Init Events’ bit is set. 
LS byte first. 
[15:14] - reserved. Write as OOb. 

Upper non-recoverable threshold is settable 

Upper critical threshold is settable 

Upper non-critical threshold is settable 

Lower non-recoverable threshold is settable 

Lower critical threshold is settable 

Lower non-critical threshold is settable 


Readable Threshold Mask (for threshold-based sensors) 

Indicates which thresholds are readable via the Get Sensor Thresholds 
command. 

[7:6]- reserved. Write as OOb. 

5] - Upper non-recoverable threshold is readable 

4] - Upper critical threshold is readable 

] - Upper non-critical threshold is readable 

] - Lower non-recoverable threshold is readable 


] Lower critical threshold is readable 
] Lower non-critical threshold is readable 


[ 
[ 
[3 
[2 
[1 
[0 
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Field Name | size |Description LI y 


21 | Sensor Units 1 1 [7:6] - reserved. Write as 11b. 

[5:3] - Rate unit 
000b = none 
001b = per uS 
010b = per ms 
011b=pers 
100b = per minute 
101b = per hour 
110b = per day 
111b = reserved 

[2:1]- Modifier unit 
00b = none 
01b = Basic Unit / Modifier Unit 
10b = Basic Unit * Modifier Unit 
11b = reserved 

0] - Percentage Ob = no, 1b = yes 

| Sensor Units 2 - Base Unit ` 


[ 
Sensor Units 2 - Base Unit 1 [7:0] - Units Type code: See Units Type Codes table. 
Sensor Units 3 - Modifier Unit [7:0] - Units Type code, 00h if unused. 


24 | Sensor Record Sharing, Sensor Byte 1: 

Direction [7:6] - Sensor Direction. Indicates whether the sensor is monitoring an input or 
output relative to the given Entity. E.g. if the sensor is monitoring a 
current, this can be used to specify whether it is an input voltage or an 
output voltage. 
00b = unspecified / not applicable 
01b = input 
10b = output 
11b= reserved 

ID String Instance Modifier Type (The instance modifier is a character(s) that 
software can append to the end of the ID String. This field selects whether the 
appended character(s) will be numeric or alpha. The Instance Modified Offset 
field, below, selects the starting value for the character.) 
[5:4] - 00b = numeric 
01b = alpha 
Share Count 
[3:0] - Share count (number of sensors sharing this record). Sensor numbers 
sharing this record are sequential starting with the sensor number 


specified by the Sensor Number field for this record. E.g. if the starting 
sensor number was 10, and the share count was 3, then sensors 10, 11, 
and 12 would share this record. 


Byte 2: 
Entity Instance Sharing 
[7]- Ob = Entity Instance same for all shared records 
1b = Entity Instance increments for each shared record 
[6:0] - ID String Instance Modifier Offset 
Multiple Discrete sensors can share the same sensor data record. The ID 
String Instance Modifier and Modifier Offset are used to modify the Sensor ID 
String as follows: 
Suppose sensor ID is “Temp ” for ‘Temperature Sensor’, share count = 3, ID 
string instance modifier = numeric, instance modifier offset = 5 - then the 
sensors could be identified as: 
Temp 5, Temp 6, Temp 7 
If the modifier = alpha, offset=0 corresponds to ‘A’, offset=25 corresponds to 
‘Z’, and offset = 26 corresponds to ‘AA’, thus, for offset=26 the sensors could 
be identified as: 
Temp AA, Temp AB, Temp AC 
(alpha characters are considered to be base 26 for ASCII) 
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byte 
26 


27 


8 
9 


0 


2 


33 


| 


Field Name 


Positive-going Threshold 
Hysteresis value 


Negative-going Threshold 
Hysteresis value 


| size | 
3 
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Positive hysteresis is defined as the unsigned number of counts that are 
subtracted from the raw threshold values to create the ‘re-arm’ point for all 
positive-going thresholds on the sensor. 0 indicates that there is no hysteresis on 
positive-going thresholds for this sensor. Hysteresis values are given as raw 
counts. That is, to find the degree of hysteresis in units, the value must be 
converted using the ‘y=Mx+B’ formula. 


Note: Cannot use shared record if sensors require individual hysteresis settings. 
Negative hysteresis is defined as the unsigned number of counts that are added 
to the raw threshold value to create the ‘re-arm’ point for all negative-going 
thresholds on the sensor. 0 indicates that there is no hysteresis on negative-going 
thresholds for this sensor. 


Note: Cannot use shared record if sensors require individual hysteresis settings. 


ID String Type/Length Code Sensor ‘ID’ String Type/Length Code, per Section 43.15, Type/Length Byte 
Format. 


ID String Bytes 


Notes: 


Sensor ID String bytes. Only present if non-zero length in Type/Length field. 
16 bytes, maximum. 


1. 7-bit FC Slave Address field. By convention, the IG slave address is represented as an eight-bit number with the least- 
significant bit always 0. E.g. 20h = 00100000b. The 7-bit Slave Address field holds the most-significant 7 bits of this value. 


E.g. 0010000b. 
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43.3 SDR Type 03h, Event-Only Record 


This record provides a mechanism to associate FRU and Entity information with a physical or logical sensor that 
generates events, but cannot otherwise be accessed. This is typical of software-generated events, such as events 
generated by BIOS. Use of this record is optional. A system is allowed to have ‘Event-Only’ sensors without 
having a corresponding Event-Only Sensor Record. 


While primarily used with software-generated events, it is possible for management controllers to implement 
*Event-Only” sensors. Such sensors must have the following characteristics: 


e The controller cannot rely on the Initialization Agent function to enable Event Generation for the sensor, 
with the exception that the sensor can be ‘globally’ enabled/disabled with the Set Event Receiver 
command. 


e Since an ‘Event-Only’ sensor is not required to support any of the sensor access commands, software 
will typically ignore the sensors and will not attempt to send IPMI commands to access or enable them. 
Thus, the controller cannot rely on any software accesses to the sensor. Therefore, the sensor cannot 
require manual-rearm for event operation. 


e The sensor cannot return a units-based sensor reading. This record lacks the necessary conversion factors 
for management software to be able to present the reading value. 


If the sensor implementation does not meet the above criteria, the appropriate Type 01h or Type 02h record must 
be used instead. 


The controller is allowed to implement IPMI sensor commands for an Event-Only sensor, such as Get Sensor 
Reading, or Get Sensor Event Status. Use of the Event-Only SDR implies that the sensor access commands are 
not explicitly supported. Therefore, software should avoid issuing sensor access commands for sensors that use 
the Event-Only SDR. 


Table 43-, Event-Only Sensor Record - SDR Type 03h 
| byte | FieldName | size | Description SS | 


HEADER 
EE VE 
access. It is not related to the sensor ID. 
SDR Version Version of the Sensor Model specification that this record is compatible with. 
5th for this specification. BCD encoded with bits 7:4 holding the Least Significant digit of 
the revision and bits 3:0 holding the Most Significant bits. 


Record Type Record Type Number = 03h, Event-Only Sensor Record 
Record Length Number of remaining record bytes following. 


RECORD KEY 

BYTES 

Sensor Owner ID [7:1] - 7-bit IPC Slave Address, or 7-bit system software ID 
[0]- Ob - ID is IPMB Slave Address, 1b = system software ID 


Sensor Owner LUN [7:4] - Channel Number 
The Channel Number can be used to specify access to sensors that are located on 
management controllers that are connected to the BMC via channels other than the 


primary IPMB. (Note: In IPMI v1.5 the ordering of bits 7:2 of this byte have changed 
to support the 4-bit channel number) 


[3:2] - FRU Inventory Device Owner LUN. LUN for Write/Read FRU commands to access 
FRU information. 00b otherwise. 


[1:0] - Sensor Owner LUN. LUN in the Sensor Owner that is used to send/receive IPMI 
messages to access the sensor. 00b if system software is Sensor Owner. 


Sensor Number 1 Unique number identifying the sensor behind the given slave address and LUN. Code FFh 
reserved. 

RECORD BODY 

BYTES 
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Field Name size | Description 
Entity ID 1 | Indicates the physical entity that the sensor is monitoring or is otherwise associated. See 
Table 43-, Entity ID Codes. 
Entity Instance 1 [7]- Ob = treat entity as a physical entity per Entity ID table 
1b = treat entity as a logical container entity. For example, if this bit is set, and the 
Entity ID is ‘Processor’, the container entity would be considered to represent a 
logical ‘Processor Group’ rather than a physical processor. This bit is typically 
used in conjunction with an Entity Association record. 
[6:0] - Instance number for entity. (See section 33.1, System- and Device-relative Entity 
Instance Values for more information) 
00h-5Fh system-relative Entity Instance. The Entity Instance number must be 
unique for each different entity of the same type Entity ID in the system. 
60h-7Fh device-relative Entity Instance. The Entity Instance number must only be 
unique relative to the management controller providing access to the 


Entity. 
Sensor Type 1 | Code representing the sensor type. From the Table 36-3, Sensor Type Codes. 
E.g. Temperature, Voltage, Processor, etc. 
Event / Reading Type Event/Reading Type Code. From the Table 36-1, Event/Reading Type Code Ranges. 
Code 


Sensor Record te 1: 
Sharing, Sensor 7:6]- Sensor Direction. Indicates whether the sensor is monitoring an input or output 
Direction relative to the given Entity. E.g. if the sensor is monitoring a current, this can be 
used to specify whether it is an input voltage or an output voltage. 
00b = unspecified / not applicable 
01b = input 
10b = output 
11b= reserved 
ID String Instance Modifier Type 
[5:4] - 00b = numeric 
01b = alpha 
Share Count 
[3:0] - Share count (number of sensors sharing this record). Sensor numbers sharing this 
record are sequential starting with the sensor number specified by the Sensor 
Number field for this record. E.g. if the starting sensor number was 10, and the share 
count was 3, then sensors 10, 11, and 12 would share this record. 


=x 


11 
2 


1 


Byte 2: 
Entity Instance Sharing 
[7]- 0b = Entity Instance same for all shared records 
1b = Entity Instance increments for each shared record 
[6:0] - ID String Instance Modifier Offset 
Multiple Discrete sensors can share the same sensor data record. The ID String Instance 
Modifier and Modifier Offset are used to modify the Sensor ID String as follows: 
Suppose sensor ID is “Temp ” for ‘Temperature Sensor’, share count = 3, ID string 
instance modifier = numeric, instance modifier offset = 5 - then the sensors could be 
identified as: 
Temp 5, Temp 6, Temp 7 
If the modifier = alpha, and offset = 26, then the sensors could be identified as: 
Temp AA, Temp AB, Temp AC 
(alpha characters are considered to be base 26 for ASCII) 


reserved. Write as 00h. 
Reserved for OEM use. 


Type/Length Code 
16 bytes, maximum. 


Notes: 

1. 7-bit FC Slave Address field. By convention, the I?C slave address is represented as an eight-bit number with the least- 
significant bit always 0. E.g. 20h = 00100000b. The 7-bit Slave Address field holds the most-significant 7 bits of this value. 
E.g. 0010000b. 


| 15 | 
| 16 | 


15 
16 
17 
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43.4 SDR Type 08h - Entity Association Record 


This record is used to present the relationship between entities that contain, or are contained by, other entities. For 
example, a particular Power Unit entity may consist of multiple Power Supply entities. In this case, the particular 
Power Unit is designated as the container entity, while the individual Power Supply entities are designated as 
contained entities. System Management Software can use this information to recognize the relationship between 
‘logical’ entities (e.g. Cooling Unit), which typically would not have FRU information, and the physical FRUs 
that comprise that unit (e.g. Fans). A ‘Group’ Entity ID is provided to be used as the container Entity if the 
container is not covered by a pre-defined Entity. 


System Management Software can use the Entity Association information to correlate events or sensor 
information between the sensors for the container entity, and the contained entity. For example, a Power Unit may 
have a redundancy sensor associated with it, while the individual Power Supplies within that Power Unit may 
have failure status sensors. In the case of a Power Supply failure, there could be two events generated - one for the 
Power Supply failure, and another for a loss of redundancy in the Power Unit. Having an Entity Association 
record allows System Management Software to determine the inter-relationship between these events. 


Each Entity Association Record can represent contained entities as a four entry list, or as up to two ranges of 
entity instances. For example, suppose you have four Power Supply entities, with Instance IDs 1, 2, 7, and 8. This 
could be listed as four separate entity/entity instance pairs, or as two ranges (range I comprised of entity instances 
1 through 2, and range 2 comprised of entity instances 7 through 8). 


Entity Association records can be ‘linked’ if necessary to extend the number of contained entities under a given 
container entity. This would be needed if there were more than four contained entities of different entity types, or 
with non-sequential instance IDs. Entity Association records that have the same Container Entity value and a non- 
zero Record Link bit are considered to be linked. The contained entities from each linked record combine to form 
the complete set of contained entities under the specified container entity. 


The Container Record Link bit informs system software there is intentionally more than one Entity Association 
record with the same Container Entity value. It is considered an error if Entity Association records are detected 
that share the same Container Entity value but do not have the Record Link bit set. In addition, Entity/Entity 
Instance ID pairs should not be repeated within an Entity Association record, nor between linked Entity 
Association records. 


This record only supports associations between entities that have system-relative Entity Instance values. See 
section 39.1, System- and Device-relative Entity Instance Values for more information 
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Table 43-, Entity Association Record - SDR Type 08h 
byte | Field Name | size | Description SS S 


RECORD HEADER 


1:2 | Record ID 2 | The Record ID is used by the Sensor Data Repository device for record organization 
ET GE and access. This may not actually be stored, but may be calculated when records are 
accessed. 
3 | SDR Version 1 Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. This is BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits. E.g. 51h 
corresponds to “1.5”. 
4 | Record Type 1 Record Type Number = 08h, Entity Association. The "RECORD KEY BYTES" includes 
the first contained entity in order to allow records to be linked according to the 
VEI Container entity ID. Thus, more than one Entity Association Record can have the same 
values for bytes 6, 7, and 8 - but must differ in bytes 9 & 10. 


Record Length Number of remaining record bytes following. 


RECORD KEY BYTES 


| 6 |] Container Entity ID Entity ID for container entity 
Container Entity Instance Instance ID for container entity 


flags [7]- Ob = contained entities specified as list 
1b = contained entities specified as range 
[6]- Record Link 
Ob = no linked Entity Association records 
1b = linked Entity Association records exist 
[5] - Ob = Container entity and contained entities can be assumed absent if presence 
sensor for container entity cannot be accessed. This value is also used if the 
entity does not have a presence sensor. 
1b = Presence sensor should always be accessible. Software should consider it 
an error if the presence sensor associated with the container entity is not 
accessible. If a presence sensor is accessible, then the presence sensor can 
still report that the container entity is absent. 
[4:0] - reserved, write as OOOOOb 


1 |Iflist: Entity ID for contained entity 1 
Range 1 entity If range: Entity ID of entity for contained entity range 1 
0 | Contained Entity 1 Instance 1 If list: Instance ID for contained entity 1 
If range: Instance ID for first entity in contained entity range 1 
RECORD BODY BYTES 


Contained Entity 2 / 
Range 1 entity 


1 


— 
= 


00h = unspecified 

If list: Entity ID for contained entity 2 

If range: Entity ID of entity for contained entity range 1 (must match byte 9) 
Set to 00h if Entity 2 is unspecified 

If list: Instance ID for contained entity 2 

If range: Instance ID for last entity in contained entity range 1 

00h = unspecified 

If list: Entity ID for contained entity 3 

If range: Entity ID of entity for contained entity range 2 

Set to 00h if Entity 3 is unspecified 

If list: Instance ID for contained entity 3 

If range: Instance ID for first entity in contained entity range 2 

00h = unspecified 

If list: Entity ID for contained entity 4 

If range: Entity ID for entity for contained entity range 2 (must match byte 13) 
Contained Entity 4 Instance / Set to 00h if Entity 4 is unspecified 

Range 2 last entity Instance If list: Instance ID for contained entity 4 

If range: Instance ID for last entity in contained entity range 2 


— 


Contained Entity 2 Instance / 
Range 1 last entity Instance 


Contained Entity 3 / 
Range 2 entity 


— 


— — 
> [do] m 


Contained Entity 3 Instance / 
Range 2 first entity Instance 


a 
oa 


Contained Entity 4 / 
Range 2 entity 


Oo 


43.5 SDR Type 09h - Device-relative Entity Association Record 


This record is the same as the Type 08h Entity Association record, except that it supports describing associations 
between entities that have device-relative Entity Instance values as well as system-relative values. See section 
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39.1, System- and Device-relative Entity Instance Values and the description for SDR Type 08h for more 
information. 


Table 43-, Device-relative Entity Association Record - SDR Type 09h 
| byte | Field Name | size |Description N] 


RECORD HEADER 


1:2 | Record ID 2 | The Record ID is used by the Sensor Data Repository device for record organization 
and access. This may not actually be stored, but may be calculated when records are 
accessed. 


3 | SDR Version 1 Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. This is BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits. E.g. 51h 
corresponds to “1.5”. 
Record Type Number = 09h, Device-relative Entity Association. The "RECORD KEY 
BYTES" includes the first contained entity in order to allow records to be linked 
according to the Container entity ID. 


Record Length Number of remaining record bytes following. 


RECORD KEY BYTES 


| 6 |ContainerEntiyID 11 Entity ID for container entity 0 
| 7 | Container Entity Instance | 1 | Instance ID for container entity | 
Container Entity Device 1 [7:1]- Slave address of management controller against which the device-relative 

Address Entity Instance for the container entity is defined. 
[0] - reserved, write as Ob 
Set to 00h if Instance ID is device-relative. 
Container Entity Device 
Channel 


Channel number of the channel that holds the management controller against 
which the device-relative Entity Instance for the container entity is defined. 

Oh if Instance ID is device-relative. 

reserved, write as 0000b. 


1 
ki 
flags 1 [ Ob = contained entities specified as list 
1b = contained entities specified as range 
[ Record Link 
Ob = no linked Entity Association records 
1b = linked Entity Association records exist 
[ Ob = Container entity and contained entities can be assumed absent if presence 
sensor for container entity cannot be accessed. This value is also used if 
the entity does not have a presence sensor. 
1b = Presence sensor should always be accessible. Software should consider it 
an error if the presence sensor associated with the container entity is not 
accessible. If a presence sensor is accessible, then the presence sensor 
R 


can still report that the container entity is absent. 

reserved, write as 00000b 

Slave address of management controller against which the device-relative 

Entity Instance for contained entity 1 is defined. 

reserved, write as Ob 

Set to 00h if Entity Instance values are device-relative. 

[7:4] - Channel number of the channel that holds the management controller against 
which the device-relative Entity Instance for contained entity 1 is defined. 
Oh if Entity Instance values are device-relative. 

3:0] - reserved, write as 0000b 

f list: Entity ID for contained entity 1 

If range: Entity ID of entity for contained entity range 1 

If list: Entity Instance for contained entity 1 

If range: Entity Instance for first entity in contained entity range 1 


Contained Entity 1 Device 
Address 


2 | Contained Entity 1 Device 
Channel 


0 
1 
3 | Contained Entity 1 / 
Range 1 Entity ID 
14 | Contained Entity 1 Instance 1 
Range 1 first entity instance 
RECORD BODY BYTES 
15 | Contained Entity 2 Device [7:1]- Slave address of management controller against which the device-relative 


1 
1 
1 
1 


Entity Instance for contained entity 2 is defined. 

[0] - reserved, write as Ob 
Set to 00h if Entity Instance values are device-relative or if the contained Entity 
entry is unspecified. 
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— 
Oo 


Contained Entity 2 Device Channel number of the channel that holds the management controller against 
Channel which the device-relative Entity Instance for contained entity 2 is defined. 
Oh if Instance ID is device-relative, if the contained Entity entry is unspecified. 
reserved, write as 0000b 
Contained Entity 2 / 00h = unspecified 
Range 1 Entity ID If list: Entity ID for contained entity 2 
If range: Entity ID of entity for contained entity range 1 (must match byte 13) 
Contained Entity 2 Instance / Set to 00h if Entity 2 is unspecified 
Range 1 last Entity Instance If list: Entity Instance for contained entity 2 
If range: Entity Instance for last entity in contained entity range 1 
Contained Entity 3 Device [7:1]- Slave address of management controller against which the device-relative 
Address Entity Instance for contained entity 3 is defined. 
[0] - reserved, write as Ob 
Set to 00h if Entity Instance values are device-relative or if the contained Entity 
entry is unspecified. 
Contained Entity 3 Device [7:4] - Channel number of the channel that holds the management controller against 
Channel which the device-relative Entity Instance for contained entity 3 is defined. 
Oh if Instance ID is device-relative, if the contained Entity entry is unspecified. 
[3:0] - reserved, write as 0000b 
Contained Entity 3 / 00h = unspecified 
Range 2 entity If list: Entity ID for contained entity 3 
If range: Entity ID of entity for contained entity range 2 
Contained Entity 3 Instance / Set to 00h if Entity 3 is unspecified 
Range 2 first entity Instance If list: Entity Instance for contained entity 3 
If range: Entity Instance for first entity in contained entity range 2 
Contained Entity 4 Device [7:1]- Slave address of management controller against which the device-relative 
Address Entity Instance for contained entity 4 is defined. 
[0] - reserved, write as Ob 
Set to 00h if Entity Instance values are device-relative or if the contained Entity 
entry is unspecified. 
Contained Entity 4 Device [7:4] - Channel number of the channel that holds the management controller against 
Channel which the device-relative Entity Instance for contained entity 4 is defined. 
Oh if Instance ID is device-relative, if the contained Entity entry is unspecified. 
[3:0] - reserved, write as 0000b 
Contained Entity 4 / 00h = unspecified 
Range 2 entity If list: Entity ID for contained entity 4 
If range: Entity ID for entity for contained entity range 2 (must match byte 21) 
Contained Entity 4 Instance / Set to 00h if Entity 4 is unspecified 
Range 2 last entity Instance If list: Entity Instance for contained entity 4 
If range: Entity Instance for last entity in contained entity range 2 


27: | reserved KS reserved 


43.6 SDR Type 0Ah:0Fh - Reserved Records 


This range and all other unspecified SDR Type values are reserved. 


N 


Co 


— 


N 
N 


N 
OT 


N 
oO 
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43.7 SDR Type 10h - Generic Device Locator Record 


This record is used to store the location and type information for devices on the IPMB or management controller 
private busses that are neither IPMI FRU devices nor IPMI management controllers. These devices can either be 
common non-intelligent DC devices, special management ASICs, or proprietary controllers. 


IPMI FRU Devices and Management Controllers are located via the FRU Device Locator and Management 
Controller Device Locator records described in following sections. 


Table 43-, Generic Device Locator Record - SDR Type 10h 
byte | Field Name | size | Description SS | 


RECORD HEADER 


1:2 | Record ID 2 | The Record ID is used by the Sensor Data Repository device for record organization 
Hi ii and access. This may not actually be stored, but may be calculated when records are 
accessed. 
3 | SDR Version 1 Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. This is BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits. E.g. 51h 
corresponds to “1.5”. 


Record Type Record Type Number = 10h, Device Locator 
Record Length Number of remaining record bytes following. 


RECORD KEY BYTES 


Device Access Address 


Slave address of management controller used to access device. 0000000b if 
device is directly on IPMB. 
reserved 


devices on a private bus, this is the slave address of the device on the private 
bus. 

Channel Number ms-bit (For IPMI 1.5. This bit was reserved for IPMI v1.0.) 
Channel Number Is-3 bits. Channel number for management controller used to 
access device. 0000b if device directly on the primary IPMB, or if controller is on 
the primary IPMB. (Note ms-bit of Channel Number is in Device Slave Address 
byte) 

[4:3] - LUN for Master Write-Read command. 00b if device is non-intelligent device 
directly on IPMB. 

[2:0] - Private bus ID if bus = Private. 000b if device directly on IPMB. 


Access LUN / Bus ID 


RECORD BODY BYTES 


Address span [7:3] - reserved 
[2:0] - number of additional consecutive slave addresses used by device. 00 indicates 
device only uses single address. 


0 
Device Type See Table 43-12, IPMB/I2C Device Type Codes 
2 | Device Type Modifier See Table 43-12, IPMB/I2C Device Type Codes 


| | 
Device Slave Address 1 7-bit PC Slave Address!!! . This is relative to the bus the device is on. For 
devices on the IPMB, this is the slave address of the device on the IPMB. For 
1 


— 


> 


Entity ID Entity ID for the FRU associated with this device. 00h if not specified. 
Entity Instance Instance number for entity. 
Reserved for OEM use. 


| 
Type/Length 
16 bytes, maximum. 


Notes: 

1. 7-bit IPC Slave Address field. By convention, the I?C slave address is represented as an eight-bit number with the least- 
significant bit always 0. E.g. 20h = 00100000b. The 7-bit Slave Address field holds the most-significant 7 bits of this value. 
E.g. 0010000b. 


+ ajafafajiajifi 
a a Oo 
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43.8 SDR Type 11h - FRU Device Locator Record 


This record is used for locating FRU information that is on the IPMB, on a Private Bus behind or management 
controller, or accessed via FRU commands to a management controller. This excludes any FRU Information that 
is accessed via FRU commands at LUN 00b of a management controller. The presence or absence of that FRU 
Information is indicated using the Management Device Locator record (see Table 43-8, Management Controller 
Device Locator - SDR 12h, below). 


Table 43-, FRU Device Locator Record - SDR Type I I h 
| byte | Field Name | size |Description Å 


RECORD HEADER 


1:2 | Record ID 2 | The Record ID is used by the Sensor Data Repository device for record organization 
lee Kai and access. This may not actually be stored, but may be calculated when records are 
accessed. 
3 | SDR Version 1 Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. This is BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits. E.g. 51h 
corresponds to “1.5”. 


Record Type Record Type Number =11h, FRU Device Locator 
Record Length Number of remaining record bytes following. 


RECORD KEY BYTES 


Device Access Address 1 [7:1] - Slave address of controller used to access device. 0000000b if device is directly 
on IPMB. (This field indicates whether the device is on a private bus or not) 

7 | FRU Device ID / Device 1 For LOGICAL FRU DEVICE (accessed via FRU commands to mgmt. controller): 

Slave Address [7:0] - Number identifying FRU device within given IPM Controller. FFh = reserved. 

The primary FRU device for a management controller is always device #0 at 

LUN 00b. The primary FRU device is not reported via this FRU Device Locator 

record - its presence is identified via the Device Capabilities field in the 

Management Controller Device Locator record. 

For non-intelligent FRU device: 

[7:1] - 7-bit PC Slave Address". This is relative to the bus the device is on. For 

devices on the IPMB, this is the slave address of the device on the IPMB. For 

devices on a private bus, this is the slave address of the device on the private 

bus. 

[0] - reserved 

| 

H 


[0] - reserved 


Logical-Physical / Access [7] - logical/physical FRU device 

LUN / Bus ID Ob = device is not a logical FRU Device 
1b = device is logical FRU Device (accessed via FRU commands to mgmt. 

controller) 

reserved. 
LUN for Master Write-Read command or FRU Command. 00b if device is non- 
intelligent device directly on IPMB. 
Private bus ID if bus = Private. 000b if device directly on IPMB, or device is a 
logical FRU Device. 
Channel number for management controller used to access device. 000b if 
device directly on the primary IPMB, or if controller is on the primary IPMB. Ms- 
bit for channel number is kept in next byte. (For IPMI v1.5. This byte position 
was reserved for IPMI v1.0.) 

[3:0] - reserved 


Channel Number 


RECORD BODY BYTES 


1 


16 | Device ID String 1 Device ID String Type/Length code per Section 43.15, Type/Length Byte Format. 
Type/Length 
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17: | Device String N | Short ‘ID’ string for the FRU Device. 
+N 16 bytes, maximum. 


Notes: 

1. 7-bit PC Slave Address field. By convention, the I?C slave address is represented as an eight-bit number with the least- 
significant bit always 0. E.g. 20h = 00100000b. The 7-bit Slave Address field holds the most-significant 7 bits of this value. 
E.g. 0010000b. 
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43.9 SDR Type 12h - Management Controller Device Locator Record 


This information is used for identifying management controllers on the IPMB and other internal channels, and for 
providing Entity and initialization information for all management controllers, including the BMC. 


Table 43-, Management Controller Device Locator - SDR 12h 
| byte [FieldName | size |Description, N] 


RECORD HEADER 


1:2 | Record ID 2 | The Record ID is used by the Sensor Data Repository device for record organization 
EE and access. This may not actually be stored, but may be calculated when records are 
accessed. 
3 SDR Version 1 Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. This is BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits. E.g. 51h 
corresponds to “1.5”. 


RECORD KEY BYTES 

Device Slave Address [7:1] - 7-bit PC Slave Address"! of device on channel. 
[0] - reserved. 

Channel Number [7:4] - reserved 


[3:0] - Channel number for the channel that the management controller is on. Use Oh 
for the primary BMC. (New byte for IPMI v1.5. Note this addition causes some 
of the following byte offsets to be pushed down when compared to the IPMI 
v1.0 version of this record.) 


RECORD BODY BYTES 


8 Power State Notification 1 Power State Notification 
Global Initialization [7]- 1b = ACPI System Power State notification required (by system s/w) 
Ob = no ACPI System Power State notification required 
[6]- 1b = ACPI Device Power State notification required (by system s/w) 


Ob = no ACPI Device Power State notification required 
[5] - For backward compatibility, this bit does not apply to the BMC, and should be 
written as Ob. 
Ob = Dynamic controller - controller may or may not be present. Software 
should not generate error status if this controller is not present. 
1b = Static controller - this controller is expected to be present in the system at 
all times. Software may generate an error status if controller is not 
detected. 
[4]- reserved 


Global Initialization 
[3]- 1b= Controller logs Initialization Agent errors (only applicable to 
Management Controller that implements the initialization agent 
function. Set to Ob otherwise.) 
[2]- 1b= Log Initialization Agent errors accessing this controller (this directs the 
initialization agent to log any failures setting the Event Receiver) 
[1:0] - 00b = Enable event message generation from controller (Init agent will set 
Event Receiver address into controller) 
O1b - Disable event message generation from controller (Init agent will set 
Event Receiver to FFh). This provides a temporary fix for a broken 
controller that floods the system with events. It can also be used for 
development / debug purposes. 
10b = Do not initialize controller. This selection is for development / debug 
support. 
11b= reserved. 
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byte [FieldName | size |Description S O 
Device Capabilities Device Support 
[7]- 1b = Chassis Device. (device functions as chassis device, per ICMB spec) 
[6]- 1b = Bridge (Controller responds to Bridge NetFn commands) 
[5]- 1b = IPMB Event Generator (device generates event messages on IPMB) 
[4]- 1b =IPMB Event Receiver (device accepts event messages from IPMB) 
[3]- 1b = FRU Inventory Device (accepts FRU commands to FRU Device #0 at 
LUN 00b) 
[2]- 1b = SEL Device (provides interface to SEL) 
[1]- 1b = SDR Repository Device (For BMC, indicates BMC provides interface to 
1b = SDR Repository. For other controller, indicates controller accepts 
Device SDR commands) 
[0] - 1b = Sensor Device (device accepts sensor commands) See Table 37-11, 
IPMB/FC Device Type Codes 


reserved reserved 
reserved reserved 
reserved reserved 


3 | Entity ID 1 Entity ID for the FRU associated with this device. 00h if not specified. If device 
supports FRU commands at LUN 00b, this Entity ID applies to both the IPM device 
and the FRU information accessed via LUN 00b. 


14 | Entity Instance Instance number for entity. 
Reserved for OEM use. 


Type/Length 
16 bytes, maximum. 


Notes: 

1. 7-bit IPC Slave Address field. By convention, the I#C slave address is represented as an eight-bit number with the least- 
significant bit always 0. E.g. 20h = 00100000b. The 7-bit Slave Address field holds the most-significant 7 bits of this value. 
E.g. 0010000b. 


10 
11 
1 
1 


BE 


al 
9101 
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43.10 SDR Type 13h - Management Controller Confirmation Record 


This record can be used by utility software to record that a given controller has been discovered in the system. 
Later, the record information can be used by software to confirm that the same controller is still present. 


Table 43-, Management Controller Confirmation Record - SDR Type 13h 
| byte [FieldName size | Description Å 


RECORD HEADER 


1:2 | Record ID 2 | The Record ID is used by the Sensor Data Repository device for record organization 
[peers GT and access. This may not actually be stored, but may be calculated when records are 
accessed. 
3 SDR Version 1 Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. This is BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits. E.g. Le 
51h corresponds to “1.5”. 


Record Type Record Type Number = 13h, Management Controller Confirmation 
Record Length Number of remaining record bytes following. 


RECORD KEY BYTES 


Device Slave Address 1. | [7:1]- 7-bit PC Slave Address"! of device on IPMB. 
[0] - reserved. Write as Ob 


Device ID from Get Device ID command. 00h = unspecified. 


Channel Number / Device 1 [7:4] - Channel Number for channel that management controller is located on. Use 0h 
Revision for the primary BMC. (New for IPMI v1.5) 
[3:0] - Device Revision from Get Device ID command, binary encoded. 


RECORD BODY BYTES 


Firmware Revision 1 Firmware Revision 1 from Get Device ID command. 

[7]- reserved. Do not compare against same bits returned from Get Device ID 
command. 

[6:0] - Major Firmware Revision, binary encoded. 


Minor Firmware Revision. BCD encoded. 

11 IPMI Version 1 IPMI Version from Get Device ID command. Holds IPMI Command Specification 
Version. BCD encoded. 00h = reserved. Bits 7:4 hold the Least Significant digit of the 
revision, while bits 3:0 hold the Most Significant bits. E.g. a value of 01h indicates 
revision 1.0 

12:14 | Manufacturer ID 3 Manufacturer ID from Get Device ID command, LS Byte first. 
Most significant four bits = reserved (0000b). 
xFFFFFh = ignore Manufacturer ID. (use for IPMI v0.9 controllers that don't provide a 


Product ID from Get Device ID command, LS Byte first. 
0000h = unspecified. FFFFh = ignore Product ID. (use FFFFh for IPMI v0.9 controllers 
that don’t provide a Manufacturer ID) 


Manufacturer ID) 
15:16 | Product ID 


17:32 | Device GUID 6 | Device GUID from Get Device GUID command. Set to all 0’s if controller doesn’t 
support Get Device GUID command. 


Notes: 

1. 7-bit PC Slave Address field. By convention, the I?C slave address is represented as an eight-bit number with the least- 
significant bit always 0. E.g. 20h = 00100000b. The 7-bit Slave Address field holds the most-significant 7 bits of this value. 
E.g. 0010000b. 
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43.11 SDR Type 14h - BMC Message Channel Info Record 


This record describes the allocation and type for the BMC message channels. This record type has been 
deprecated for IPMI v1.5. IPMI v1.5 systems should use the Get Channel Info command instead. 


Table 43-, BMC Message Channel Info Record - SDR Type 14h 
byte | Field Name | size | Description SS | 


RECORD HEADER 


The Record ID is used by the Sensor Data Repository device for record organization 
and access. This may not actually be stored, but may be calculated when records are 
accessed. 

SDR Version Version of the Sensor Model specification that this record is compatible with. 
Oth for this specification. This is BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits. Note this 
record keeps the IPMI v1.0 version number. 


Record EE Record Type Number - 14h, BMC Message Channel Info 
Record | 5 | Record Lengih | 1 [Number of remaining record bytes following. — | Number of remaining record bytes following. 


| REGORD BODY BYTES I 


Message | 6 | Message Channel 0 Info | 1 | Channel 0, if present, is pre-defined to be the channel used for communication with the | 0 Info Channel 0, if present, is pre-defined to be the channel used for communication with the 
IPMB. Thus, the Message Channel 0 Info field either has bits 3:0 = Oh, indicating 
‘channel not present’, or a constant ‘10100001’ (A1h) if an IPMB is present. 

The following bit definitions apply to the Message Channel Info fields for all channels: 
[7]- 1b = Transmit supported 
Ob = receive message queue access only 
[6:4] - Message Receive LUN 
000b-011b = LUN to receive messages from this channel. 
111b = no LUN associated with receiving messages from this channel. 
all other = reserved 
Channel Protocol - this indicates the data format messages received from the 
channel in the Receive Message Queue and the format of data to be used for 
the Send Message command. 
Oh = Channel not present / not used. 
Mi IPMB 
= ICMB v1.0 
= ICMB v0.9 
the SMBus v1.0 Host (the controller must accept being addressed as a 
slave, and accept the SMBus Modified Write Word protocol. The 
interface may optionally accept a full SMBus Write Block. An SMBus 
channel can simultaneously support low-level DC devices, but not IPMI 
| 7 | ES 


devices) 

5h = System Format (Request messages of the format defined by the system 
interface: e.g. NetFn/LUN, Command, Data. Response messages as: 
NetFn/LUN, Command, Completion Code, Data - with the same 
messages size limitations as standard IPMI messages delivered over 
the system interface.) 

Ch-Fh = OEM Protocol 1 through 4, respectively 

all other = reserved 


7 1 
| 8 |Channel2info | 1 [Message Channel2Info S O 
| 9 |Channel3 Into | 1 [Message Channel3Info o 
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Field Name -sze [Description __LLLLLu———— 


14 | Messaging Interrupt Type OOh-OFh = IRQ 0 through 15, respectively 
10h-13h = PCI A-D, respectively 
14h = SMI 


15h = SCI 
20h-5Fh = system interrupt 0 through 63, respectively 


60h = assigned by ACPI / Plug ‘n Play BIOS 
FFh = no interrupt 
all other = reserved 


15 | Event Message Buffer ea see types defined for Messaging Interrupt Type byte 14 in this record. 
Interrupt Type 


reserved reserved 1 1 | reserved 
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43.12 SDR Type COh - OEM Record 


These record type numbers are reserved for OEM definition. OEM defined records are limited to a maximum of 64 
bytes, including the header. 


Note: OEM unique records should be avoided when possible. The amount of space available for these record 
types is implementation dependent and may be limited. 


Table 43-, OEM Record - SDR Type COh 
[byte | Field Name (age | Description N] 


RECORD HEADER 


The Record ID is used by the Sensor Data Repository device for record organization 
and access. This may not actually be stored, but may be calculated when records are 
accessed. 

2 

Version of the Sensor Model specification that this record is compatible with. 
51h for this specification. This is BCD encoded with bits 7:4 holding the Least 
Significant digit of the revision and bits 3:0 holding the Most Significant bits. 


Manufacturer ID Manufacturer ID code. LS Byte first. Most significant 4 bits = reserved (0000b). 
000000h = unspecified, OFFFFFh =reserved. This value is binary encoded. E.g. the ID 
for Intel Corporation is 343 decimal, which is 157h, which would be stored in this record 
as 57h, O1h, 00h for bytes 6 through 8, respectively. 


9: | OEM Data N | OEM Data. N bytes. 
2+N 
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43.13 Device Type Codes 


These codes are used to identify different types of devices on an IPMB, PCI Management Bus, or Private 
Management Bus connection to an IPMI management controller. 


Table 43-, IPMB/FC Device Type Codes 


‘Heceta’ ASIC or similar 00h = Heceta 1 e.g. LM78 
01h = Heceta 2 e.g. LM79 
02h = LM80 
03h = Heceta 3 e.g. LM81/ ADM9240 / DS1780 
04h = Heceta 4 
05h = Heceta 5 
EEPROM, 24C01 or equivalent EEPROM Use: 
00h = unspecified 
01h = DIMM Memory ID 
02h = IPMI FRU Inventory 
03h = System Processor Cartridge FRU / PIROM 
(processor information ROM) 
all other = reserved 


10h FRU Inventory Device behind management controller 00h = IPMI FRU Inventory |" 
(accessed using Read/Write FRU commands at LUN other 01h = DIMM Memory ID 
than 00b) 02h = IPMI FRU Inventory!" 
03h = System Processor Cartridge FRU / PIROM 
(processor information ROM) 


all other = reserved 
FFh = unspecified 


Gore Logic (Chip set) Device, specific device not specified 00h = unspecified 


OEM specified device 
1. Either value can be used. The 00h Device Type Modifier is present for backward compatibility. The remaining modifiers line up 
with those for the 08h-OFh Device Types. 


LMC6874 Intelligent Battery controller, or equivalent 00h = unspecified 
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43.14 Entity IDs 


The Entity ID field is used for identifying the physical entity that a sensor or device is associated with. If multiple 
sensors refer to the same entity, they will have the same Entity ID field value. For example, if a voltage sensor 
and a temperature sensor are both for a ‘Power Supply 1’ entity the Entity ID in their sensor data records would 
both be 10 (OAh), per the Entity ID table. 


Table 43-, Entity ID Codes 


o | om [mse i 


| 6 | oen | 
system board (main system board, may also be a processor board and/or internal expansion board) 
memory module (board holding memory devices) 


processor module (holds processors, use this designation when processors are not mounted on 
system board) 


power supply (DMI refers to this as a "power unit”, but it's used to represent a power supply). 
Use this value for the main power supply (Supplies) for the system. 
Other system board (part of board set) 


processor board (holds 1 or more processors - includes boards that hold SECC modules) 
power unit / power domain - This Entity ID is typically used as a pre-defined logical entity for grouping 
power supplies and/or sensors that are associated in monitoring a particular logical power domain. 
20 14h power module / DC-to-DC converter - Use this value for internal converters. 


Note: You should use Entity ID 10 (power supply) for the main power supply even if the main supply is 
a DC-to-DC converter, e.g. gets external power from a -48 DC source. 


cooling unit / cooling domain - This Entity ID can be used as a pre-defined logical entity for grouping 
fans or other cooling devices and/or sensors that are associated in monitoring a particular logical 
cooling domain. 


cable / interconnect 


32 20h memory device -This Entity ID should be used for replaceable memory devices, e.g. DIMM/SIMM. It 
is recommended that Entity IDs not be used for individual non-replaceable memory devices. Rather, 
monitoring and error reporting should be associated with the FRU [e.g. memory card] holding the 


memory. 


37 


25h Group - This is a logical entity for use with Entity Association records. It is provided to allow an Entity- 


association record to define a grouping of entities when there is no appropriate pre-defined entity for 
the container entity. This Entity should not be used as a physical entity. 


26h Remote (Out of Band) Management Communication Device 
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Entity 


External Environment - This Entity ID can be used to identify the environment outside the system 
chassis. For example, a system may have a temperature sensor that monitors the temperature 
“outside the box”. Such a temperature sensor can be associated with an External Environment entity. 
This value will typically be used as a single instance physical entity. However, the Entity Instance 
value can be used to denote a difference in regions of the external environment. For example, the 


region around the front of a chassis may be considered to be different from the region around the 
back, in which case it would be reasonable to have two different instances of the External 
Environment entity. 


at EE 


ENE. blade (a blade module that contains processor, memory, and VO connections that enable 
it to operate as a processing entity) 


EIE switch (a blade module that provides the fabric or network connection for one or more 
processing blades or modules) 


Processor/memory module (processor and memory together on a module) 
Processor/ IO module (a combination processor and i/O module) 
Management Controller Firmware (Represents firmware or software running on a management 
controller) 
IPMI Channel - This Entity ID enables associating sensors with the IPMI communication channels - for 
example a Redundancy sensor could be used to report redundancy status for a channel that is 
composed of multiple physical links. By convention, the Entity Instance corresponds to the channel 
number. 
| 52 | 34h | Processor/front-sidebus | 
| 53 _36h_| Real Time Glock (RTO) — BEE EES EER EE 


reserved. This Sr was previously a duplicate of 22h (System Firmware). This value should remain 
reserved for any future versions of the specification to avoid conflicts with older applications that may 
interpret this as System Firmware. 


| 55 | 37h | air inlet - This Entity ID enables associating sensors such as temperature to the airflow at an air inlet. | 
56-63 38h-3Fh | reserved. (This value was previously a duplicate of 22h (System Firmware). This value should remain 
eg reserved for any future versions of the specification to avoid conflicts with older applications that may 
eg interpret this as System Firmware.) 
air inlet - This Entity ID enables associating sensors such as temperature to the airflow at an air inlet. 
This Entity ID value is equivalent to Entity ID 37h. It is provided for interoperability with the DCMI 1.0 
specifications. 
processor / CPU - This Entity ID value is equivalent to Entity ID 03h (processor). It is provided for 
interoperability with the DCMI 1.0 specifications. 
baseboard / main system board - This Entity ID value is equivalent to Entity ID 07h (system board). It 
is provided for interoperability with the DCMI 1.0 specifications. 
| | 90h-AFh | Chassis-specific Entities. These IDs are system specific and can be assigned by the chassis provider. 


BOh-CFh | Board-set specific Entities. These IDs are system specific and can be assigned by the Board-set 
provider. 

DOh-FFh | OEM System Integrator defined. These IDs are system specific and can be assigned by the system 
integrator, or OEM. 


| - | | all other values reserved 


* = DMI standard groups compatible. These codes can be mapped to corresponding codes in the DMI Systems Standard 
Groups Definition MIF. 


43.15 Type/Length Byte Format 


The type/length byte is a variation of the type/length byte format defined in the Platform Management FRU 
Information Storage Definition. The main differences being that bit 5 is reserved in the IPMI specification 
type/length byte, where it is part of the length field in the Platform Management FRU specification, and bits 7:6 = 
00b define a Unicode string in the IPMI specification, whereas they specify a binary field in the Platform 
Management FRU specification. 
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Type/Length Byte definition: 
7:6 00 = Unicode 
01 = BCD plus (see below) 
10 = 6-bit ASCII, packed 
11 = 8-bit ASCII + Latin 1. At least two bytes of data must be present when this type is used. Therefore, the 
length (number of data bytes) will be >1 if data is present, 0 if data is not present. A length of 1 is 
reserved. 
5 reserved. 
4:0 length of following data, in characters. 00000b indicates ‘none following’. 11111b = reserved. 


BCD PLUS definition: 
Oh - 9h = digits 0 through 9 


Ah = space 

Bh = dash '-' 

Ch = period ‘.’ 

Dh = colon '” 

Eh = comma ‘,’ 

Fh = underscore * ` 


Table 43-, 6-bit ASCII definition 
o [sp |zo Jo [20 le Lois 
2 D far Ji fafa [31 [0 | 
2 |" fi2 [2 [22 | 
3 [4 [13 13 123 | 


+ 
LA 


LE | 


GJ OJ OI GO EA KOST EA G] G] G] OG w 


ele [25 [oe [26 | 
EE EES ER 
8 Ji EER fe EH 
9 DP EEN EN [29] 
a [ra 1: [aa] 
© p EEN EN ER 
EN e EEN 


> 


E 
m 
Ki 
N 
E 
w 
å 


"ASCII+LATIN1" is derived from the first 256 characters of Unicode 2.0. The first 256 codes of Unicode follow 
ISO 646 (ASCII) and ISO 8859/1 (Latin 1). The Unicode "CO Controls and Basic Latin" set defines the first 128 8- 
bit characters (00h-7Fh) and the "C1 Controls and Latin-1 Supplement" defines the second 128 (80h-FFh). 


"6-bit ASCII" is the 64 characters starting from character 20h (space) from the ASCH+LATINI set. So 6-bit ASCII 
value 000000b maps to 20h (space), 000001b maps to 21h (!), etc. Packed 6-bit ASCII takes the 6-bit characters and 
packs them 4 characters to every 3 bytes, with the first character in the least significant 6-bits of the first byte. A 
table of 6-bit ASCII codes and an example of packed 6-bit ASCII characters follows: 
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43.16 6-bit ASCII Packing Example 
"IPMI" encoded in 6-bit ASCII is: 
l= 29h (101001b) 
P= 30h (110000b) 
M= 2Dh (101101b) 
l= 29h (101001b) 


Which gets packed into bytes as follows: 


Figure 43-, 6-bit Packed ASCII Example 
bit 7 6 5 4 3 2 1 0 hex 
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43.17 Sensor Unit Type Codes 


The following type codes are encodes units from the International System of Units, selected additional ‘imperial’ 
measures, and common ‘computer’ and communication measurements. 


Table 43-, Sensor Unit Type Codes 


[Gode [Unt | Code [Unt J code [un | 
0 | unspecified | 34 [m | [meget | 
[1 Taegreesc | 35 [cum eg [oot | 
[6 [was La | steradians | 74 | word (data) | 
dword 
8 | Coulombs | 42 Loge | 76 [awor 
rit f eo [ry — | 
reset 

e 

Ca 

Ca 

Ca 

SC 

400 | 


umen 
lux 


| 90 | uncorrectable error | 


A 

Pa 
PSI 
N 


second 


100 


[mm | 


mm 


BEEN 
| 26 | | 60 | 


554 


Intelligent Platform Management Interface Specification 


44. Examples 


44.1 Processor Sensor with Sensor-specific States & Event 
Generation 


The following example shows a Processor sensor that has sensor specific discrete state information. The Sensor 
Type Code for Processor is 07h. A sensor that uses sensor-specific state information is identified using an 
Event/Reading Type Code of 6Fh in the SDR. 


Sensor Type: Processor = 07h (From Table 42-, Sensor Type Codes) 
Event/Reading Type: Sensor-specific = 6Fh (From Table 42-, Event/Reading Type Code Ranges) 


The example processor sensor returns the following readings 
IERR, Thermal Trip, and Processor Presence 
and generates the following events: 
IERR Asserted, Processor Presence Asserted, Processor Presence Deasserted 


The Reading Mask and Event Mask fields in the SDR for the sensor is used to tell System Management Software 
that these are the only possible readings that the sensor will return. System Management Software can use this 
information to customize the way it displays or acts on the sensor state and sensor events. The same State Bit field 
positions that are used for the masks are also used in commands for accessing and configuring the sensor, such as 
the Get Sensor Reading and Set Sensor Event Enable commands. 


Note that, for this example, the events that can be generated are a subset of the possible states that can be read 
from the sensor, and that the deassertion events don’t necessarily match up with the assertion events. Most sensors 
will be this way. In fact, in a typical implementation most sensors will not generate any deassertion events. The 
guideline is that warning and error conditions should generate Event Messages (and be logged) while non-critical 
or informational state changes should not. This helps ensure that the event log and event receiver does not get 
clogged up with non-critical information. Event Messages do not utilize the state bit field directly - but instead use 
an 4-bit offset value corresponding to the State Bit position of the state change that triggered the event. The 4-bit 
offset helps keep Event Messages compact, allowing for additional parameter bytes to be passed with the event 
while keeping the size of SEL Event Records at 16 bytes. While a discrete sensor can simultaneously track and 
report multiple states, a consequence of using an offset in the Event Message is that only one state change event at 
a time gets reported in an Event Message. 


An Event Dir bit used in Event Messages and SEL Event Records indicates whether the event was an assertion 
event (0) or a deassertion event (1). For example, if a Processor Presence Detection event occurred the Event 
Message would contain an offset value of 7, with an event dir bit of 0. 
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Table 44-, Example discrete Processor sensor with Sensor-specific states & event generation 


SDR SDR SDR 
Reading Assertion Deassertion 
State Bit Mask Event Mask Event Mask 


ERR a OE a 1 | o Ek 
[Thermal Trip AR | 1 | 1 ln f) o Ef 
| FRB1/BIST failure pf a | 2 | o | o In | 
| FRB2/Hangin POST failure Ja | 3 | o | o | o | 
| FRB3/Processor Startup/inttfalre | aa | 4 | o | o | o | 
| Configuration Error (forDM) | sn | 5 | o | o | o | 
| SMBIOS ‘Uncorrectable CPU-complex Error | eh | 6 | 0 | o | o | 
| ProcessorPresencedeteeted | m | 7 | 1 | 1 | 1 | 
| Processor disabled an | 8 | o | o | o | 
| Terminator Presence Deteeted La | 9 | o | 0 | o | 
[unspecified i | m | 10 | o | o | o | 
[unspecified pf mm oa | o | o | o E 
[unspecified pomp 1 | o | o | o | 
[unspecified ppm [18 | 0 | o | o | 
unspecified en a | oo [0 [0 
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44.2 Processor Sensor with Generic States & Event Generation 


Even though the Processor sensor type has sensor-specific states defined, that doesn’t mean you have to use them. 
You can use the generic discrete states with any sensor type. In this example, we show the definition of a 
Processor sensor that returns a generic severity state. 


Sensor Type: Processor 07h (from Table 42-, Sensor Type Codes) 


Event/Reading Type: generic Severity 07h (from Table 42-, Event/Reading Type Code Ranges and Table 
42-, Generic Event/Reading Type Codes) 


In this example, assume that we return the following Severity status: 

OK, Non-Critical from OK, Non-Critical from more severe, Critical from less severe 
and generate events on the following transitions 

Non-Critical from OK, Critical from less severe 


Note that this definition only generates events on worsening severity conditions. This is a recommended practice 
to avoid filling the SEL with non-failure related information. 


The following table shows the event offsets returned in event messages, the state bits returned from the ‘Get 
Sensor Reading’ command, and the Assertion / Deassertion Masks in the SDR corresponding to a sensor with the 
example characteristics. 


Table 44-, Example discrete Processor sensor with Generic states & event generation 


SDR SDR SDR 
Reading Assertion Deassertion 
State Bit Mask Event Mask Event Mask 


ftransiiontoOK So | ol i | o | o | 
| transition toNon-Critical fromOK | m | 1 | 1 | 1 | o | 
| transition to Critical trom lesssevere | an | 2 | 1 | | o | 
| transition to Non-recoverable from less severe | 2 | 3 | 0 | 0 | o | 
| transition to Non-Critical from more severe | ah | 4 | 1 | oO | o | 
| transition to Critical fromNon-recoverable | shn | 5 | 0 | oO | o | 
| transition to Non-recoverabe øm | 6e | o | o | o | 
[Montor o ajf 7 | o0 | o | o | 
[Informational 1 an | 8 | o | 0 In E 
reserved I en | 9 | o | 0 [0 | 
reserved AT 10 | o | o | o ë 
[reseved > ES f o | oi | o Ef 
reserved Oh e | o | o | o |] 
EE j e | o | o | o | 
[reserved EL 1 To [0 [0 
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Appendix A - Previous Sequence Number 
Tracking 


The following illustrates how a method for tracking the last eight received sequence numbers can be used for 
handling out-of-sequence packet reception. The method illustration assumes that the receiver tracks the highest 
received sequence number that has been accepted, shown as ‘Highest Received’ column, and which of the previous 
eight sequence numbers have been received, shown as the ‘Previously Received List’. 


Note that for implementation, the previously received list can be implemented as a bit field where 1=received, 0=not 
received, and the bit positions correspond to sequence numbers for Highest Received-1, Highest Received-2, 
Highest Received-3, etc. The handling of wrap-around of the sequence number is not shown and is left to the reader. 
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Startup initialization. Highest Received session sequence number is set to value that was sent with the 
Activate Session command. The Previously Received List is initialized as if the preceding eight sequence 
numbers were received. This prevents a packet with a sequence number less than the initial value from 
being accepted. For this example, assume the initial sequence number is 40. 


Initial values are: 
Highest Received Previously Received List 

40 39 | 38 | 37 | 36 | 35 | 34 | 33 | 32 
Y Y Y Y Y Y Y Y 


Packet 41 is received. Packet is accepted because it is no more than 8 counts greater than the Highest 
Received value from step 1. Highest Received becomes 41. Previously received list gets ‘pushed up’. 
Updated values are: 
Highest Received Previously Received List 

41 40 | 39 | 38 | 37 | 36 | 35 | 34 | 33 
Y Y Y Y Y Y Y Y 


Packet 44 received. Accepted because it is within 8 counts of the last Highest Received. Highest Received 
becomes 44. Previous received list gets pushed up by 2. Note that packets 43 and 42 are listed as 
unreceived. Updated values are: 
Highest Received Previously Received List 

44 43 | 42 | 41 | 40 | 39 | 38 | 37 | 36 
N N Y Y Y Y Y Y 


Packet 39 received. Dropped because it is a duplicate with previously received packet. No update to 
Highest Received and Previously Received List. Updated values are: 
Highest Received Previously Received List 

44 43 | 42 | 41 | 40 | 39 | 38 | 37 | 36 
N N Y Y Y Y Y Y 


Packet 42 received. Accepted because it is listed as unreceived on the Previously Received List. Packet 42 
listed as received. No update to Highest Received because 42 is not higher than 44. Updated values are: 
Highest Received Previously Received List 

44 43 | 42 | 41 | 40 | 39 | 38 | 37 | 36 
N Y Y Y Y Y Y Y 
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Appendix B - Example PEF Mask Compare 
Algorithm 


This is an ‘untested’ algorithm provided as a starting point for guiding an implementation. While this looks a lot like 
C code, consider this as pseudo-code - or just read the comments... 


Figure B-1, Example Event Data Comparison Algorithm 


pfs reete here wê go eer 
// First, make a value that has the ‘don’t care’ bits forced to 0 
temp1 = (test_value & AND mask); 


// Next, check it for a match with the ‘exact match’ bits 

// (AND'ing with comparel forces the ‘non-exact’ bit positions to 0. 

// By AND’ing templ with compare 1, and compare2 with comparel the result is two 
// values that both have the ‘non-exact’ bit positions forced to 0. The 

// remaining non-forced bit positions should match. 
if ((templ & comparel)==(compare2 & comparel)) { // they match 

match = true; // so far! this may change! (innocent until proven guilty) 


// Now see if there are ‘non exact’ bits to check 
if (comparel != OxFF) { // yep, there are non-exact bits to check 


// Make a value that has both the ‘don’t care’ and the ‘exact compare’ 
// bits forced to 0. 
temp2 = templ & !comparel; 


// then AND it with compare2. If the result is non-zero, you 

// had at least one ‘1’ in the right place. 

// (But first check if compare2 is 0. If so, there are no 1’s to check for.) 
if (compare2 != 0x00) { 

if !(temp2 & compare2) match = false; // No 1’s in right places 

DÉI 


// Take temp2 and AND with NOT compare2 to look for 0's. 

// (But first check if compare2 is FF. If so, no 0's to check for.) 
if (compare2 != OxFF) { 

if !(temp2 & !compare2) match = false; // No 0's in right places 
DÉI 


} else (match = false); // ‘exact match’ bits didn’t match 


// somewhat nastier condensed version (test value variable re-use, logical test 
// used for detecting non-zero values, etc.) 


// sets variable “match”: 0 = no match, non-zero = match. 
[Poe sec se EE se sedate sa OE OE EE AE EE DEE EE EE EE 
testValue &= AND mask; // force don't care bits to 0 
// then check the ‘exact match’ bits 
if ((testValue & comparel)==(compare2 & comparel)) { 
match = 1; // so far, so good 
if (comparel != OxFF) { // we have ‘non-exact’ bits to check 
testValue &= !comparel; // force ‘exact match’ bits to 0, too 


if (compare2) match = testValue & compare2; // look for 1’s in right places 
// look for 0's in right places, but not unless we still have a match 
if (match && (compare2 != OxFF)) match = ! (testValue & !compare2); 
DÉI 
) else (match=0); 
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Appendix C1 - Locating IPMI System Interfaces 
via SM BIOS Tables 


The System Management BIOS Reference Specification, Version 2.3.1, March 16, 1999 (hereon referred to as SM 
BIOS) includes the following optional record for identifying the initial location of IPMI system interfaces and 
interrupts. This is summarized in the following table. Fields in BOLD represent fields that are additions to the 2.3.1 
specification. See [SMBIOS] for other application information on SM BIOS. 


Note that the settings that this structure reports may be over-ridden by ‘Plug-and-Play’ reassignment by the OS. 
Therefore, this structure should be used only when the interface cannot be discovered via ‘Plug-and-Play’ discovery 
mechanisms incorporated in interfaces such as PCI and ACPI. 

IPMI Device Information (Type 38). 


Table C1-1, SM BIOS IPMI Device Information Record 


Offset | Name Length Value | Description 

00h Type BYTE 38 IPMI Device Information structure indicator. 
(Note this number is given in decimal) 

Oih Length BYTE Length of the structure, a minimum of 10h (for 
full IPMI address description, this is a minimum 
of 12h) 

02h Handle WORD | Varies 

04h Interface Type BYTE ENUM | Baseboard Management Controller (BMC) 


interface type, see Table C1-2, Interface Type 
field values, below. 


05h IPMI BYTE Varies | Somewhat mis-named. Actually identifies the 
Specification IPMI Specification Version, in BCD format, to 
Revision which the BMC was designed. Bits 7:4 hold the 


most significant digit of the version, while bits 
3:0 hold the least significant bits, e.g. a value 
of 15h indicates version 1.5. 

06h | 1°C Slave BYTE 32 The slave address on the IC bus of this BMC. 
Address (This refers to the address of the BMC on the 
primary IPMB, if present. This value is set to 
20h [0010_000x] per the IPMB specification.) 
07h NV Storage BYTE Varies | Bus id of the NV storage device. If no storage 
Device Address device exists for this BMC, or if the device 
cannot be accessed with the Read / Write FRU 
Data commands, the field is set to OFFh. (This 
refers to the address of the primary FRU 
device if the BMC implementation allows that 
device to be accessed with the Master Write- 
Read commands as well as the Read / Write 
FRU Data commands.) 

08h Base Address QWORD | Varies | Identifies the base address (either memory- 
mapped or I/O) of the BMC. If the least- 
significant bit of the field is a 1, the address is 
in VO space; otherwise, the address is 
memory-mapped. If the BMC uses SSIF, the 
first byte of the Base Address field holds the 
Slave Address of the BMC on the SMBus from 
the host controller, and the remaining bytes are 
set to OOh. (The 7-bit slave address is left- 
justified in the least-significant byte and the 
least significant bit of the byte set to Ob. E.g. a 
slave address of 0010000b is stored in this 
field as: 00_00_00_00_00_00_00_20h. 
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10h Base Address BYTE Varies | Base Address Modifier (This field is unused 
Modifier / and set to 00h for SSIF) 
Interrupt Info bit 7:6 - Register spacing 


00b = interface registers are on 
successive byte boundaries 
01b = interface registers are on 32-bit 
boundaries 
10b = interface registers are on 16-byte 
boundaries 
11b = reserved 
bit 5 - reserved. Return as Ob. 
bit 4 - LS-bit for addresses 
Ob = Address bit 0 = Ob 
1b = Address bit 0 = 1b 


Interrupt Info 
Identifies the type and polarity of the interrupt 
associated with the IPMI system interface, if 
any. 
bit 3 - 1b = interrupt info specified 
Ob = interrupt info not specified 
bit 2 - reserved. Return as Ob. 
bit 1 - Interrupt Polarity. 
1b = active high, Ob = active low. 
bit O - Interrupt Trigger Mode. 
1b = level, Ob = edge. 
11h Interrupt Number BYTE Varies | Interrupt number for IPMI System Interface. 
00h = unspecified / unsupported 


C1-1 IPMI Device Information - BMC Interface 


The following sections present more information describing the Type 38 record fields and their use. 


C1-1.1 Interface Type 


The following table presents the meaning of the values for the Interface Type Field: 


Table C1-2, Interface Type field values 


Byte Value Meaning 
00h Unknown 
Oih KCS: Keyboard Controller Style 
02h SMIC: Server Management Interface Chip 
03h BT: Block Transfer 
04h SSIF: SMBus System Interface 
05h to OFFh | Reserved for future assignment by this specification 


C1-1.2 IPMI Specification Revision Field 


Identifies the IPMI Specification Revision, in BCD format, to which the BMC was designed. Bits 7:4 hold the most 
significant digit of the revision, while bits 3:0 hold the least significant bits, e.g. a value of 10h indicates revision 
1.0. 


C1-1.3 BC Slave Address Field 


This field indicates the slave address of the BMC on the primary IPMB in the system. The most significant seven 
bits hold the address. The least significant bit is reserved and shall be returned as Ob. The 7-bit portion of the slave 
address for the BMC is 0010 000_b, therefore this field will typically be populated with the value 20h. 
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C1-1.4 NV Storage Device Address Field 


The field is reserved for use by the System Integrator (party that integrates motherboard and chassis). 
This field describes the location of an auxiliary OEM NV Storage Device on the primary IPMB in the system. 


C1-1.5 Base Address Field 


This field is used to describe the base address for the BMC’s system interface. The field can describe both I/O 
mapped and memory-mapped base addresses. The least significant bit of this field indicates whether the base 
address is an I/O address or a memory address. The most significant 63-bits of this field holds the most significant 
63 bits (bits 63:1) of a 64-bit address. The least significant bit (bit 0) of the base address is kept in the Base Address 
Modifier field. 


All IPMI system interface registers are inherently non-cacheable and the register locations must be implemented as 
non-cacheable addresses. 


C1-1.6 Base Address Modifier Field 


This field provides the least-significant bit for the base address, information indicating how the system interface 
registers are aligned (either on byte, 32-bit, or 16-byte boundaries). 


C1-1.7 System Interface Register Alignment 

System interface registers can optionally be defined on 32-bit or 16-byte boundaries. In this case, the registers are 
32-bits (4 bytes) apart. Base Addresses must match the specified register alignment. For example, the base address 
for a 32-bit aligned interface must have its two least significant address bits = 00b. Thus, the LS bit field in the Base 
Address Modifier is always Ob for non-byte-aligned addresses. 


C1-1.7.1 Byte-spaced I/O Address Examples 

The following example shows how the default system interface addresses would be represented in the SM BIOS 
Base Address and Base Address Modified fields. Base Address bit 0 = 1b indicates that the base address is an I/O 
address. The default system interface definition specifies that the system interface registers occupy consecutive byte 
locations. Thus, the register spacing in the Base Address Modifier is set to Ob. Note that the LS bit field in the Base 
Address Modifier field matches the least-significant bit listed in the corresponding addresses from the Default Base 
Address column. 


Table C1-3, Byte-aligned I/O Mapped Register Address examples 


LS bit Register 

Interface Default Base Address | SM BIOS Base Address field spacing 
KCS OCA2h 0000 0000 0000 CA3h Ob 00b 
SMIC OCA9h 0000 0000 0000 CA9h 1b 00b 
Block Transfer (BT) 00E4h 0000 0000 0000 00E5h Ob 00b 


C1-1.7.2 32-bit Spaced VO Address Examples 
The following example shows examples addresses for a KCS interface implemented with 32-bit aligned registers at 
I/O base address CACh. 


Table C1-4, 32-bit aligned I/O Mapped Register Address examples 


LS bit | Register spacing 
Example I/O Address | SM BIOS Base Address field 
base address 0000 OCACh 0000 0000 0000 OCADh Ob 01b 
Data In 0000 OCACh 0000 0000 0000 OCADh Ob 01b 
Data_Out 0000 OCACh 0000 0000 0000 OCADh Ob 01b 
Command 0000 OCBOh 0000 0000 0000 OCBih Ob 01b 
Status 0000 OCBOh 0000 0000 0000 OCB1h Ob 01b 
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C1-1.7.3 Memory-mapped Base Address 
For memory-mapped system interfaces, the Base Address field and Base Address Modifier are used in the same 
manner as for an I/O-mapped interface, except that Base Address bit 0 is set to Ob. 


C1-1.7.4 Interrupt Info Field 
This field identifies the type and polarity of the interrupt associated with the IPMI system interface, if any. Refer to 
the Type 38 table, above, for individual bit descriptions. 


C1-1.8 Interrupt Number Field 


This field holds the interrupt number for the IPMI System Interface. The field is set to OOh when the number is 
unspecified or an interrupt is not supported. 
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Appendix C2 - Locating IPMI System Interfaces 
on PCI 


The PCI SIG (http://www.pcisig.com) has defined class codes for IPMI System Interfaces in Appendix D of the PCI 
Local Bus Specification, Revision 2.3, March 29, 2002. PCI-based implementations of the IPMI System Interfaces 
should use the appropriate PCI configuration space and the class code definition there to report the presence and 
type of system interface for driver loading purposes. 


A BMC is allowed to support more than one type of system interface simultaneously. It is possible Only an active 
BMC should respond to the Get Device ID command. 


The first base address register of the PCI function holding the IPMI System Interface. The IPMI System Interfaces 
can be I/O or memory mapped, as indicated by read-only bits in the base address register. 


Unless otherwise specified, IPMI System Interfaces on PCI must be byte aligned and located at offset 0 with respect 
to the base address register. PCI implementations of the KCS interface that are not byte-aligned must return a fixed 
OOh in the unused byte positions. This enables a driver to test for alignment. Non- byte-aligned KCS interfaces must 
also have their eight-bit registers aligned on even 32-bit or 16-byte boundaries starting at offset 0 with respect to the 
base address register. 


Table C2-1, PCI Class Codes for IPMI 
Class Sub Interface | Description 
Code | Class 
OCh Serial Bus Controllers (Historically, the IPMI System Interfaces were defined 
under this class because of the use of BMCs as interfaces to serial busses such 
as private management busses and the IPMB) 


07h IPMI System Interfaces 
00h IPMI SMIC Interface 
Oih IPMI Keyboard Controller Style (KCS) Interface 
02h IPMI Block Transfer (BT) Interface 
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Appendix C3 - Locating IPMI System Interfaces 
with ACPI 


Revision 1.2 of the IPMI v1.5 specification introduces the option of describing the presence of the IPMI System 
Interface as a static (non- “Plug and Play”) resource using ACPI. The IPMI System Interface can also be 
implemented as a relocate-able resource on PCI (refer to Appendix C2 - Locating IPMI System Interfaces on 
PCD. 


There are two ACPI-based mechanisms that work together when the IPMI System Interface is implemented as a 
static resource, the Service Processor Management Interface (SPMI) Description Table and ACPI Control 
Methods. 


C3-1 SPMI Description Table and ACPI Control Methods 


The SPMI Description Table is an optional table that describes the processor-relative, translated, fixed resources 
of an IPMI system interface at system boot time. The purpose of the SPMI Table is to provide a mechanism that 
can be used by the OSPM (an ACPI term for “OS Operating System-directed configuration and Power 
Management” essentially meaning an ACPI-aware OS or OS loader) very early in the boot process, e.g., before 
the ability to execute ACPI control methods in the OS is available. 


The SPMI Description Table is similar to the SMBIOS Type 38 (IPMI Device Information) record. The main 
difference between the two is that the SPMI Table is identified in the ACPI Specification as a table that has the 
reserved signature “SPMI”. The SMBIOS Type 38 record type is from the SMBIOS specifications from the 
Distributed Management Task Force (http://www.dmtf.org) pre-OS working group. 


The SPMI Description Table can be used to describe the location of either fixed resource or PCI 
implementations of the system interface. For system interfaces on PCI, the table can only describe the location 
of the system interface at the time that the boot process is initiated. An OS may relocate these resources. 
Therefore, whether or not a PCI-based system interface remains at the SPMI addresses is OS-dependent. During 
normal run-time operation, software should locate the system interface directly on PCI and/or use the OS’s 
support for PCI instead of the SPMI Table. 


A management controller device may present more than one system interface for IPMI messaging to the BMC. 
For example, a BMC may simultaneously support the KCS and the BT interfaces. A unique SPMI Table should 
be provided for each of these interfaces. This allows the OSPM to select an interface that it is able to 
communicate and hence maximize the supportability. 


Per [ACPI 2.0], unless otherwise specified, numeric values for the table and any blocks or structures are always 
encoded in little endian format. Signature values are stored as fixed-length strings. 


Table C3-1, Service Processor Management Interface Description Table Format 


Byte Byte 
Field Length Offset Description 


Header Poet EE 


Signature ER RM ‘SPMI’. Signature for the Service Processor Management 
Interface Table. 

Length Length, in bytes, of the entire Service Processor 
Management Interface Table. 

Revision EE je 

Checksum | 1 | 9 | Entire table must sum to zero. 


OEMID 10 OEM ID. Per ACPI specification. An OEM-supplied string that 
identifies the OEM. 
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Byte Byte 
Field Length Offset 
m un 
OEM Revision 4 24 


— 
Bi 


Interface Type 1 36 


Specification Revision 2 38 
(version) 

Interrupt Type 1 40 
GPE 1 41 


Reserved 


PCI Device Flag 1 43 


Global System Interrupt 


Description 
For the Service Processor Management Interface Table, the 
table ID is the manufacturer model ID (assigned by the OEM 
identified by “OEM ID”). 
OEM revision of Service Processor Management Interface 
Table for supplied the given OEM Table ID. Per ACPI, this is 
“An OEM-supplied revision number. Larger numbers are 
assumed to be newer revisions.” 
Vendor ID of utility that created the table. For the tables 
containing Definition Blocks, this is the ID for the ASL 
Compiler. 
Revision of utility that created the table. For the tables 
containing Definition Blocks, this is the revision for the ASL 
Compiler. 
Indicates the type of IPMI interface: 
0 Reserved 
1 Keyboard Controller Style (KCS) 
2 Server Management Interface Chip (SMIC) 
3 Block Transfer (BT) 
4 SMBus System Interface (SSIF) 
5-255 Reserved 
This field must always be 01h to be compatible with any 
software that implements previous versions of this spec. 
Identifies the IPMI specification revision, in BCD format, to 
which the interface was designed. The first byte holds the 
most significant digits, while second byte holds the least 
significant digits of the revision, e.g. a value of 0x0150 
indicates the interface is compatible with IPMI version v1.5. 
Interrupt type(s) used by the interface: 
[7:2] - Reserved (must be 0) 
[1]- VO APIC/SAPIC interrupt (Global System Interrupt) 
[0]- SCI triggered through GPE (use Ob for SSIF) 

0 = not supported 

1 = supported 
The bit assignment of the SCI interrupt within the GPEx_STS 
register of a GPE described if the FADT that the interface 
triggers. (Note: This field is valid only if Bit[0] of the Interrupt 
Type field is set. Otherwise set to 00h.) 
OOh. 
[7:1] - Reserved 
[0] - PCI Device Flag. For PCI IPMI devices, this bit is set. For 
non-PCI devices, this bit is cleared. When this bit is cleared, 
the PCI Segment Group, Bus, Device and Function Number 
fields combined corresponds to the ACPI UID value of the 
device whose HID or CID contains IPI0001 plug and play 
ID. UID must be an integer. Byte 60 contains the least 
significant byte of the _UID value. Set to Ob for SSIF. 
The I/O APIC or VO SAPIC Global System Interrupt"! used by 
the interface. (Note: This field is valid only if Bit[1] of the 
Interrupt Type field is set. Otherwise set to 00h.) 
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Byte Byte 
Field Length oset Description 
Base Address 12 The base address of the interface register set described 
using the Generic Address Structure (GAS, See [ACPI 2.0] 
for the definition). The Address_Space_ID field in the GAS 
can only be of the value of 0 (System Memory), 1 (System 
IO), and 4 (SMBus). All other values are not permitted. 
For SSIF: 
The Address Space ID = 4 and the address field of the GAS 
holds the 7-bit slave address of the BMC on the host SMBus 
in the least significant byte. Note that the slave address is 
stored with the 7-bit slave address in the least significant 7- 
bits of the byte, and the most significant bit of the byte set to 
Ob. 
Register Bit Width = 0 
Register Bit Offset = 0 
Address Size field = 1 (Byte access) 
Address = 7-bit SMBus address of BMC SSIF 
PCI Segment Group PCI Segment Group Number, if the IPMI device is a PCI 
Number / UID byte 1 Eat Otherwise, this field is byte 1 of a UID. See 
Eat for PCI Device Flag, above. 
PCI Bus Number / UID ER Fm PCI Bus Number, if the IPMI device is a PCI device. 
byte 2 mal. this field is byte 2 of a UID. See description for 
PCI Device Flag, above. 


PCI Device Number / ME 62 PCI Device fields or byte 3 of a UID. Per PCI Device Flag, 
UID byte 3 above. 
For PCI Device Flag = 1b: 
[7:5] - Reserved 
[4:0] - PCI Device Number: The PCI device number if the 
IPMI device is a PCI device. 
For PCI Device Flag = 0b: 
[7:0] - byte 3 of UID 


PCI Function Number / 1 63 PCI Device fields or byte 4 of a UID. Per PCI Device Flag, 
UID byte 4 above. 
For PCI Device Flag = 1b: 
[7]- Reserved 
[6]- Interrupt Flag: 
Ob = interrupt not supported 
1b = interrupt supported 
[5:3] - Reserved 
[2:0] - PCI Function Number: The PCI function number if 
the IPMI device is a PCI device. 
For PCI Device Flag = Ob: 
[7:0] - byte 4 of UID 


Reserved 1 64 This field must always be null (0x00) to be compatible with 
any software that implements previous versions of this spec. 
This field is a deprecated “SPMI ID Field”. Implementations 
based on pre-IPMI v2.0 versions of SPMI may contain a null- 
terminated string here. 


1. ACPI represents all interrupts as “flat” values known as global system interrupts. Therefore to support APICs or SAPICs on an 
ACPI-enabled system, each used APIC or SAPIC interrupt input must be mapped to the global system interrupt value used by 
ACPI. See Section “Global System Interrupts” in [ACPI 2.0] for a description of Global System Interrupts. 


C3-2 Locating IPMI System Interfaces in ACPI Name Space 


The SPMI Description Table provides a mechanism that can be used before the ability to execute ACPI control 
methods in the OS is available. This table is not, however, intrinsically supported in the OSPM as a way of 
discovering and reporting system resources. Therefore, it is recommended that non-PCI IPMI System Interfaces on 
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the baseboards be described in the ACPI name space. This makes it possible for the OSPM to enumerate the IPMI 
System Interface as a device. In addition, the ACPI name space description is more flexible and friendly in hot-plug 


scenarios. 


Note that to be ACPI compatible, the fixed resources for IPMI System Interfaces must still be accounted for in 
accordance with the ACPI specification. If the device is not formally described in the ACPI Name Space, its 

resources must be described as fixed system resources or the resources appended to some other fixed resource 
system device in order to ensure that the OSPM does not attempt to allocate those resources to some other device. 


To formally describe the IPMI System Interface in ACPI Name Space, an IPMI device is created using the named 
device object. The IPMI device object can have the following elements: 


Table C3-2, IPMI Device Object Control Methods 


Object 
_ADR 


-HID 


CID 


STR 


-UID 


_CRS 


_STA 


_IFT 


` SRV 


Description 


Named object that evaluates to the interface’s address on its parent bus. 
_ADR is a standard device configuration control method defined in the ACPI 
Specification. 


Named object that provides the interface's Plug and Play identifier. This 
value can be vendor specific but must set to IP100017 if no CID object is 
provided. HID is a standard device configuration control method defined in 
the ACPI Specification. 

Named object that provides the interface's compatible Plug and Play 
identifier. This object is required and contains the value of IPIO001 if HID 
contains vendor specific identifier. Otherwise, this object is optional. 

Named object that evaluates to a Unicode string that may be used by an OS 
to provide information to an end user describing the device. __STR is a 
standard device configuration control method defined in the ACPI 
Specification. 

Named object that specifies a device’s unique persistent ID, or a control 
method that generates it. UID is a standard device configuration control 
method defined in the ACPI Specification. 

Named object that returns the interface's current resource settings. System 
Processor Management Interfaces are considered static resources; hence 
only return their defined resources. The address region definition is interface 
type/subtype dependent. CRS is a standard device configuration control 
method defined in the ACPI Specification. 

Object that returns the status of the device: enabled, disabled or removed, 
as defined in the ACPI Specification. If this method is not present, the 
device is assumed to be enabled. 

Object that specifies the interface type, as defined in the SPMI Table. (Note: 
IFT and _SRV, following, have been reserved in ACPI 3.0 as names for 
control methods defined for SPMI) 

Object that specifies the specification revision, as defined in the SPMI 
Table. 


Support Level 


Required only for 
devices on a bus 
that has standard 
enumeration 
mechanism. 
Required 


See description 
to left 


Required 


Required if more 
than one device 


Required 


Recommended 


Required 


Required 


7 Intel has registered the IPIxxxx PNP ID with Microsoft for describing all IPMI related devices. Intel has granted the use of IPI0001 
to describe the generic Service Processor Management Device as defined in this specification. 
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_GPE | Named object that evaluates to either an integer or a package. If GPE Required if 
evaluates to an integer, the value is the bit assignment of the SCI interrupt interrupt through 
within the GPEx_STS register of a GPE block described in the FADT that GPE is supported 
the Service Processor Management Interface will trigger. 

If GPE evaluates to a package, then that package contains two elements. 
The first is an object reference to the GPE Block device that contains the 
GPE register that will be triggered by the interface. The second element is 
numeric (integer) that specifies the bit assignment of the SCI interrupt within 
the GPEx_STS register of the GPE Block device referenced by the first 
element in the package. 


(Note: This object is only provided if the interface supports a GPE.) 


NOTE: Normally PCI based devices are not described in ACPI name space. OSPM should use the PCI enumeration 
mechanism to locate IPMI interfaces. See Appendix C2 - Locating IPMI System Interfaces on PCI. 


If the IPMI interface supports interrupts, the interrupt descriptor in CRS is used if the interrupt is supported via IO 
(S)APIC, while _GPE object is used if the interrupt is supported through the GPE register. Having both the interrupt 
descriptor in CRS and the _GPE object in the IPMI device scope is not permitted by this specification. 


If the IPMI interface does not support interrupts, neither the interrupt descriptor in the CRS nor the GPE object 
will be present. 


In a multi-node system where there may be more than one IPMI device in an OS domain, it is highly recommended 
that all IPMI devices be described in the ACPI name space with the _STA returning enabled for the active IPMI 
device(s). 


C3-3 Example IPMI Definition ASL Code 


Example ASL code that defines IPMI System Interfaces is shown below: 


Example 1: SMIC Interface in VO Space 
Example ASL for describing an IO-port based SMIC system interface: 


Device (MIO) { 
Name (_HID, EISAID("IPIOOO1") ) 
Name ( STR, Unicode ("IPMI_SMIC")) // Optional, but recommended 


// for identifying IPMI system interface. // The strings "IPMI_KCS", 
"IPMI SMIC", 
// and "IPMI_BT" are recommended for 
// identifying the KCS, SMIC, and BT 
// interfaces, respectively. 
Name(_UID, 0) // UID for the primary IPMI system interface in the system 


// Returns the "Current Resources" 
Name ( CRS, 
ResourceTemplate() { 
IO(Decodel6, OxCA9, 0, 3) // Ports OxCA9, OxCAA & OxCAB 
} 
) 


// Returns the interface type 
Method(_IFT) { 

Return(0x02) // IPMI SMIC 
} 


// Returns the interface specification revision 
Method(_ SRV) { 

Return(0x0100) // IPMI Specification Revision 1.0 
} 
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//This interface does not support interrupt 


Example 2: KCS Interface in 64-bit Address Space 


Example ASL for describing a memory-mapped KCS system interface, located in a 64-bit address space at address 


0x80000FFFFCO20CA2: 


Device (MIO) { 
Name ( HID, EISAID("IPIOOO1")) 


Name ( STR, Unicode ("IPMI KCS")) // Optional, but recommended 


// 


Name ( UID, 


// Returns the 


for identifying IPMI system interface. 
// The strings "IPMI KCS", "IPMI SMIC", 


// and "IPMI BT" are recommended for 
// identifying the KCS, SMIC, and BT 
// interfaces, respectively. 


0) // UID for the primary IPMI system interface in the system 


"Current Resources" 


Name ( CRS, 


ResourceTemplate() { 
QWordMemory ( 
ResourceConsumer, if 
PosDecode, // 
MinFixed, // 
MaxFixed, // 
NonCacheable, // 
ReadWrite, // 
OxFFFFFFFFFFFFFFFF, // GRA, Address granularity. 
// E.g. All 64-bits decoded. 
Ox80000FFFFCO20CA2, // MIN, Address range minimum 
// (System I/F base addr.) 
Ox80000FFFFCO20CA4, // MAX, Address range max 
0x0000000000000000, // TRA, Translation. 
// 0 for non-bridge devices 
0x0000000000000002, // LEN, Address range length 
` // Resource Source Index 
` // Resource Source Name 


r // A name to refer back to this resource 
, // MTP, Nothing=>AddressRangeMemory 
, // _TTP, Translation. Nothing=>TypeStatic 
// TypeTranslation: This resource, which is memory 
// on the secondary side of the bridge is I/O on the 
// primary side of the bridge. 
// TypeStatic: This resource, which is memory on 
// the secondary side of the bridge is also memory 
// on the primary side of the bridge. 
) 
} 
) 


// Returns the interface type 
Method(_IFT) { 
Return (0x01) // IPMI KCS 


} 


// Returns the interface specification revision 
Method (_SRV) { 
Return (0x0100) // IPMI Specification Revision 1.0 


} 


// This interface does not support interrupt 
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Example 3: SMIC Interface in VO Space 


Example ASL for describing a memory-mapped BT system interface using a fixed interrupt 


Device (MIO) { 

Name ( HID, EISAID("IPIOOO1")) 

Name ( STR, Unicode ("IPMI BT")) // Optional, but recommended 
// for identifying IPMI system interface. 

// The strings "IPMI_KCS", "IPMI_SMIC", 

// and “IPMI BT" are recommended for 
// identifying the KCS, SMIC, and BT 
// interfaces, respectively. 


Name ( UID, 0) // UID for the primary IPMI system interface in the system 


// Returns the "Current Resources" 


Name ( CRS, 

ResourceTemplate() { 
IO(Decodel6, Ox0E4, 0, 3) // Ports OxE4h:E6h 
Interrupt (ResourceProducer,..) {20} // GSI is 20 


i 
) 


// Returns the interface type 
Method(_IFT) { 

Return(0x03) // IPMI BT 
} 


// Returns the interface specification revision 
Method( SRV) { 

Return(0x0150) // IPMI Specification Revision 1.5 
) 


Example 4: SSIF Interface 


Example ASL for describing the presence of the SSIF. In order to associate the SSIF with a particular SMBus host 
controller interface, the SMBus host controller must be described as a resource under ACPI and the SSIF defined as 
a device under the host controller. E.g.: 


Device (SMBO) // example SMBus host controller 

{ 
Name ( HID, "<Vendor-Specific HID>") // Vendor-Specific HID 
Name ( UID, 0) // Unique ID of particular host controller 


Device (SSIF) 

{ 
Name ( HID,"IPIOOO1") // IPMI system interface 
Name ( UID, 0) // Unique device identifier 
Name ( STR, Unicode ("IPMI_SSIF") 


// Returns the interface type 
Method _IFT 


Return (0x04) // Return interface type for SSIF 


// Returns the SSIF slave address 
Method _ADR 


Return (0x10) //Return SSIF Slave Address (e.g. 00010000b, left justified) 


// Returns the interface specification version 
Method (_ SRV) 
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{ 
Return(0x0200) // IPMI Specification Version 2.0 
} 


} // end Device SSIF 
} // end Device SMBO 
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Appendix D - Determining Message Size 
Requirements 


Two factors drive the message size support requirements. The first is the message size limit of the IPMB. The 
IPMB is specified to have a 32-byte maximum overall message length (from slave address through the last 
checksum byte). The second is the ability for the Master Write-Read command to be able to be used to support 
SMBus 2.0 protocols for accessing slave devices and supporting SMBus 2.0 channels in the BMC. 


The largest SMBus 2.0 transaction is the Block-Write with PEC (Packet Error Code) protocol transaction. The 
Block-Write with PEC protocol transaction requires 36 bytes (including slave address) to be transferred as a 
single write transaction on SMBus. 


e IPMB Message : 32 bytes, maximum, including slave address. 
e SMBus 2.0 Message: 36 bytes, maximum, including slave address. 


Local system software can use the BMC as a low-level controller to access private management busses, the IPMB, 
and SMBus connections by sending a Master Write-Read command to the BMC through the system interface. 
Using a Master Write-Read command to deliver a full-size SMBus 2.0 Block-Write protocol transaction requires 
accepting a 40 byte message over the KCS system interface (see following figure). Note that while the SMBus 
message is 36 bytes overall, the Slave Address is already part of the Master Write-Read command, so only 35 
bytes is shown in the write data portion of the message. 


Figure D-1, SMBus Write-Block by Master Write-Read through KCS/SMIC 


NetFn/LUN Command Bus ID Slave Address Read [Write Data] total 
Count 
1 1 1 1 1 35 36 
(Slave address for (Command, byte count, 
SMBus Write- data, & PEC for SMBus 
Block with PEC) Write-Block with PEC) 


Similarly, the BMC needs to accept 36 bytes on any connection where the BMC could be the target of an SMBus 
2.0 Write-Block protocol. 


The SMBus 2.0 Block-Read operation only requires 34 bytes of input. (Byte Count, 32 data bytes, and PEC). Soa 
private management bus that accessed SMBus 2.0 devices as a slave would only need to support 34 input bytes. 
(Note there’s no slave address read from a Read-Block because the device is acting as a slave on the bus.) 
Therefore, the following show the size of Master Write-Read Response required to be delivered from the IPMB 
and KCS interfaces: 


Figure D-2, Master Write-Read Response via KCS/SMIC 
NetFn/LUN Command Completion Code Read Data total 
1 1 1 34 37 
(bytecount, data, and 
PEC for SMBus Read- 
Block with PEC) 


For comparison, the following shows the Get Message Response that would return an entire 32-byte message in 
IPMB format. 


Figure D-3, Get Message Response via KCS/SMIC 
NetFn/LUN Command Completion Code Channel # Read Data | total 
1 1 1 1 32 36 
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LAN or PPP IPMI request message for a Master Write-Read message to perform an SMBus 2.0 Block-Write with 
PEC protocol transaction: 


Figure D-4, Master Write-Read Request via LAN/PPP 


Software NetFn/ Check 1 RasA RqSeq CMD Bus Slave Read [Write Check2 | total 
ID LUN /LUN ID Address Count Data] 


1 1 1 1 1 1 1 1 1 35 1 45 


LAN or PPP IPMI response message for a Master Write-Read response that returns data for an SMBus 2.0 
Block-Read with PEC protocol transaction. The SMBus Block-Read with PEC protocol requires reading a 
maximum of 34 bytes from the bus (byte count, 32-bytes of data, and PEC). 


Figure D-5 Master Write-Read Response via LAN/PPP 


Software NetFn/ Check 1 RqSA RqSeq CMD completion [Read | Check2 | total 
ID LUN /LUN code Data] 


1 1 1 1 1 1 1 34 1 42 


Private Bus Write from IPMB. Maximum Write Data that is supported to a private management bus using the 
Master Write-Read command delivered via IPMB: 


Figure D-6, Master Write-Read Response via LAN/PPP 


RsSA NetFn/ Check 1 RqSA RqSeq CMD Bus Slave Read [Write Check 
LUN /LUN ID Address Count Data], max 2 


1 1 1 1 1 1 1 1 1 22 1 
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Appendix E - Terminal Mode Grammar 


E-1 Notation 


[x] = x occurs one or more times. E.g. X, XX, XXXXX 

[x |y|z] =A set consisting of one or more occurrences of x, y, or z in any order or combination. E.g. Z, zyz, 
XZYXYZZXY 

(x ly) = Exclusive OR. Only one of x or y, but not both. 

{x} = Optionally present. x may or may not occur. 

BOLD = A string literal. Case insensitive unless otherwise noted. 


E-2 Grammar for Terminal Mode Input 


input_line ::= start cmd_prefix space (command | message ) {space} input_termination_seq 

start ::= L bracket 

cmd-prefix ::= SYS 

command ::= (password cmd | set cmd | reset cmd | power. cmd | health cmd | comset cmd | 
oem cmd ) 

message ::= message segment ( { space ] line continue message segment } 


input termination seg ::= stop input newline 


password cmd ::= login cmd | null login cmd | logout cmd 

login cmd ::= PWD space -U space username (space password) 
null login cmd ::= PWD space -N (space password) 

logout cmd ::= PWD space -X 

set cmd ::= SET space ( set boot | set_tcfg ) 

set boot ::= BOOT space hex pair 

set tcfg ::= TCFG space ( (set. volatile) | (set non-volatile) } 
set volatile ::= -V space hex pair hex pair 

set non-volatile ::= -N space hex pair hex pair 

reset cmd ::= RESET space 

power cmd ::= POWER space ( ON | OFF ) 

health cmd ::= HEALTH space QUERY (space opt verbose) 
oem cmd ::= oem id space printable 
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username ::= 


password ::= 


message segment ::= 
line continue ::= 
stop ::= 


input newline ::= 


oem id ::= 

opt verbose ::= 
printable ::= 
alphanumeric ::= 


punctuation ::= 


alpha ::= 
digit ::= 

hex pair ::= 
hex ::= 


L bracket :: 


R bracket :: 


Space ::= 
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[ alphanumeric | punctuation] 

// username is limited to 16 characters. Spaces are not allowed in usernames that work 
with terminal mode. 

[ alphanumeric | punctuation ] 

// password is limited to 16 characters. Spaces are not allowed in the terminal mode 
password. 

hex-pair (space message segment) 

backslash input newline 

R bracket 

(cr| null) 

// note: A configuration option affects which of these in-termination options may be 
enabled at a time. 

hex_pair hex_pair hex_pair hex_pair hex_pair hex_pair 

-V 

[ alphanumeric | punctuation | space ] 

[ digit | alpha ] 

[ ! | double-quote | #|$ | % | & | apostrophe | (|) | * | + | grave_accent | 

hyphen | period |/|:|3|<|>|?|@| backslash | | underscore | { | vertical bar | tilde ] 
// note that the L_bracket and R_bracket characters not part of this set. 

a-z | A-Z 

0-9 


hex hex 


[ digit | a-f | A-F ] 


E-3 Grammar for Terminal Mode Output 


output_line ::= 


output_termination_seq :: 


output_newline ::= 


start ( ok response | error. response | OEM. response | handshake ) 
output termination seg 


stop out termination 


Cer lf | cr | If | null) / Only one type used at a time. Configurable. 
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ok_response ::= OK { {space} command. response } 

error_response ::= ERR {space err_code} 

command response ::= (output newline) printable (output newline (printable)! 

OEM response ::= SYS space oem id printable (output newline {printable} ) 

handshake ::= SYS 

err_code ::= hex-pair 

oem_id ::= hex_pair hex_pair hex_pair hex_pair hex_pair hex_pair 

printable ::= [ alphanumeric | punctuation | space ] 

alphanumeric ::= [ digit | alpha ] 

punctuation ::= [ ! | double-quote | #|$ | % | & | apostrophe | (|) | * | + | grave accent | 


hyphen | period |/ |: |; |< |> |? | @ | backslash |^ | underscore | { | vertical bar | tilde ] 
// note that L_bracket and R_bracket characters not part of this set. 


alpha ::= [a-z | A-Z ] 

digit ::= [0-9] 

hex pair ::= hex hex 

hex ::= [ digit | a-f | A-F ] 
L bracket ::= [ 

R bracket ::= ] 

space ::= “> //20h 
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Appendix F - TAP Flow Summary 


The following table presents implementation notes and an overview of the flow of a TAP page from a BMC. The 
table is intended as a guideline and does not supercede the TAP specification. Refer to [TAP] for complete 
information on implementing the Telocator Access Protocol. 


Table F-1, TAP Flow Summary 


Remote Entry Device 


Paging Terminal 
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step (BMC) (Paging Service) Description 
1 Dial up the paging service. 
Use the ATDT modem 
command to start the 
modem. The modem 
returns one of the 
following: 
CONNECT 
NO CARRIER 
OK 

2 Connection established 

3 <CR> The carriage return <CR> is repeated at 
t1 (2) second intervals until the paging 
company responds with ID= at the 
correct baud rate or until n1 (3) 
transmissions of <CR> have been 
completed. 

4 ID= Request for ID should be returned 
within t2 (1) second of the receipt of 
<CR>. The paging service may send 
<CR>, <LF>, <CR><LF>, or <LF><CR> 
after the ID=. The BMC should ignore 
extra characters after the ID=. Refer to 
the TAP spec for implementation advice 
on handling <LF> characters that may 
be received from the paging service. 
The paging service waits up to t5 (8) 
seconds for response to "ID=". The 
paging service may resend "ID=" up to 
n3 (3) times if a proper response is not 
received. 

5 ESC>PG1<CR> <ESC> signifies that the BMC wants to 

or for password entry: communicate with the paging company 
<ESC>PG1pppppp<CR> in automatic mode. 


"PG" signifies the type of service to be 
accessed and the types of fields in the 
message. P indicates that the message 
contains a “Pager ID” field and G 
indicates presence of a message text 
field. The paging service provider 
determines whether a Pager ID is used 
with the message text. Note that PG will 
typically be used even if the Pager ID 
field is empty. 


The next character represents the type 
of terminal or device attempting to send 
the pages: 
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‘1’ is a category using the same 
protocol. Refer to [TAP] for other field 
values. 


The 6-character pppppp stands for an 
up to six character alphanumeric 
password. Password is optional. The 
paging service provider determines 
whether a password should be used. 


When an incorrect logon sequence 
beginning with <ESC> is received, the 
paging company sends "ID=" back to 
indicate a retry is requested. 


<Message Sequence> 
followed by either: 


A message sequence is defines as a 
series of short messages separated by 
<CR>’s. The first characters of each 
response message are a three ASCII 
digit response code. A <CR> always 
follows the message sequence. 


<CR><ACK><CR> 


Logon accepted 


or: <CR><NAK><CR> 


Retry Logon 


or: <CR><ESC><EOT><CR> 


Forced disconnect by paging service. 
The BMC firmware should drop the 
transmission on the <EOT> and not 
require a <CR> to follow the <EOT>. 


6a 


(optional) 
<Message Sequence> <CR> 


The paging service may insert a 
greeting message sequence at this 
point. 


<ESC>[p<CR> 


The paging service is ready to receive 
the first transaction. Note that the ‘p’ is 
in lowercase. 


This response should be received within 
t3 (10) seconds after step 6 / 6a. 


<STX> 
Pager_ID<CR> 
Message<CR> 
<ETX> 
Checksum<CR> 


The message transaction should be 
sent within t4 (4) seconds of getting the 
step 7 response from the paging 
service. Message data is transferred as 
a series of blocks, with message strings 
(fields) within a block. A field is a series 
of characters with <CR> indicating end- 
of-field. 


A block begins with <STX> and ends 
with a TAP checksum followed by a 
<CR>. The last character before the 
checksum is set to either <ETB> if the 
paging transaction takes multiple 
blocks, <US> if a field spans blocks, or 
<ETX> if the transaction ends within the 
block. The pages sent by IPMI consist 
of a single block with two fields: 

Field 1 : Pager ID (a.k.a. PIN) 

Field 2 : Message 

This format is shown in the Remote 
Entry Device column. 
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The Pager ID number is determined by 
the paging service. Most Pager IDs are 
7 ASCII numeric characters long. Note 
that there’s no restriction in the spec on 
the maximum length for a Pager ID, nor 
any restriction that the paging service 
only require numeric characters. Any 
characters in the 7-bit ASCII set, 
including control characters, may be 
required. 


The response to each block (step 9) 
should be sent by the paging service 
within t3 (10) seconds of receiving the 
block. If the response is not received, 
the block may be resent. This can be 
repeated up to n2 (3) times before the 
BMC gives up and drops the line. 


<Message Sequence> 
followed by either: 


The specification indicates that there 
should be a message sequence from 
the paging service at this point, which 
should be a 3-character response code. 
However, it’s possible that some paging 
service implementations will skip 
sending it. 


The BMC thus should accept an ACK/ 
NAK/ Reject/ or EOT sequence without 
a preceding message sequence. Per 
the TAP spec, older versions of TAP did 
not send a message sequence, and 
earlier implementations may just send 
<Ctrl-code><CR> instead of <CR><Ctrl- 
code><CR>. 


It's recommended that the BMC accept 
either the 2- or 3-character versions of 
the ACK/ NAK/ Reject/ or EOT/ 
sequences in order to provide a level of 
backward compatibility with earlier TAP 
services. 


<CR><ACK><CR> 


Message acknowledged, ready for next 
block (if any). 


or: <CR><NAK><CR> 


Message NAK’d (not acknowledged). 
Typically due to a checksum or 
transmission error. Resend block. 


or: <CR><RS><CR> 


Transaction rejected. Don't retry. 
Transaction violates TAP protocol, field 
contents (e.g. Pager ID) were invalid, or 
other issue with the paging service. The 
BMC should give up and terminate the 
page at this point. It’s probably best to 
follow the TAP spec and send an 
<EOT><CR> and wait for acknowledge 
from the paging service rather than just 
dropping the phone connection. 


or: <CR><ESC><EOT><CR> 


Forced disconnect by paging service. 
The BMC firmware should drop the 
transmission on the <EOT> and not 
require a <CR> to follow the <EOT>. 
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10 <EOT> <CR> Sent to paging service to indicate the 
end of the paging transactions. 
11a (optional) The paging service may insert a 
<Message Sequence><CR> termination message sequence at this 
point. 
11b (optional) The paging service may indicate a 
<RS><CR> transaction reject at this point. 
11c <ESC><EOT><CR> The paging service should indicate the 


drop connection & hang up. 


end of the transaction by transmitting 
this sequence and hanging up at this 
point. While the specification doesn’t 
state this, it’s recommended that the 

BMC resend <EOT><CR> at “t6”* (2) 
“n4”* (3) times until acknowledged. 


The reason for this provision is to help 
ensure that the page transaction is 
accepted. 


Regardless, the BMC should time out 
after t3 (10) seconds after sending the 
last <EOT><CR> and drop the 
connection. 


* t6 and n4 are new timing /retry parameters just associated with the IPMI specification. 
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Appendix G - Command Assignments 


The following lists the commands defined in this specification and the minimum privilege level required to 
execute a given command. In addition, the following apply: 
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Unless otherwise specified, unauthenticated, session-less interfaces, such as the System Interface and 
IPMB, can support any IPMI command. 


The privilege level requirements for OEM commands (NetFn=OEM, OEM/Group) is specified by the 
OEM identified by the corresponding manufacturer ID. 


Note that the Send Message and Master Write-Read commands are not available at the User privilege level, 
with the exception of using a Send Message command to deliver a message to the System Interface. This is 
because these commands enable unfiltered access the IPMB, ICMB, private management busses, and PCI 
Management Bus. This would potentially allow someone to use those commands to send commands to 
other controllers or write to non-intelligent devices on those busses. As a consequence, a User is only able 
to read FRU and sensors directly managed by the BMC. In addition, FRU must be accessed via the Read 
FRU command and not Master Write-Read. 


The Send Message command can be used to deliver a message to the System Interface at User privilege 
level. It is up to the system software to determine the privilege level and place any additional restrictions on 
messages received via the Receive Message Queue. This can be accomplished by using the session handle 
associated with the message and the Get Session Info command to look up the privilege level that the user 
is operating at. Software can also check the limits for the channel and the user by using information from 
the Get Channel Access and Get User Access commands to determine whether a given user has sufficient 
privilege to deliver a particular command to system software. 


Unless otherwise specified, the listed IPMI commands, if supported, must be accessible via LUN 00b. 


Key for Command Privilege Levels Table: 


b= command only generated by BMC, can be sent prior to a session being established 
bl = command only generated by BMC, can only be delivered to a session-less channel, or a channel that 
has an active session 
b2= command only generated by BMC, can be sent to a serial channel when serial port sharing is used and 
activating the SOL payload causes the serial session to be terminated. 
b3 = command only generated by BMC, can only be delivered to a session-less channel. 
p= works at any privilege level, can be sent prior to a session being established 
s= command executable via system interface only 
= supported at given privilege level or higher 
l= command executable from local interfaces only (e.g. IPMB, SMBus, PCI Mgmt. bus or System 
Interface) 
= Callback privilege 
= User Privilege level 
= Operator Privilege level 
= Administrator Privilege level 
App = Application Network Function Code 
S/E = Sensor/Event Network Function Code 
-=  Reserved/unassigned, or OEM specified 
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Table G-, Command Number Assignments and Privilege Levels 


section NetFn CMD C U (0) A 
IPM Device “Global” Commands 
reserved S App 00h - S S - 
Get Device ID 20.1 App Oth x 
Broadcast ‘Get Device ID’ 20.9 App Oth | | 
Cold Reset 20.2 App 02h x 
Warm Reset 20.3 App 03h x 
Get Self Test Results 20.4 App 04h x 
Manufacturing Test On 20.5 App 05h x 
Set ACPI Power State 20.6 App 06h x 
Get ACPI Power State 20.7 App 07h x 
Get Device GUID 20.8 App 08h x 
Get NetFn Support 21.2 App 09h x 
Get Command Support 218 App OAh x 
Get Command Sub-function Support 21.4 App OBh x 
Get Configurable Commands 21.5 App OCh x 
Get Configurable Command Sub-functions 21.8 App ODh X 
unassigned = App OEh-OFh = - = - 
Set Command Enables 21.7 App 60h x 
Get Command Enables 21.8 App 61h x 
Set Command Sub-function Enables 21:9 App 62h x 
Get Command Sub-function Enables 21.10 App 63h x 
Get OEM NetFn IANA Support 21.11 App 64h x 
BMC Watchdog Timer Commands 
Reset Watchdog Timer 27.5 App 22h x 
Set Watchdog Timer 27.6 App 24h x 
Get Watchdog Timer 27.7 App 25h x 
BMC Device and Messaging Commands 
Set BMC Global Enables 22.1 App 2Eh s s s s 
Get BMC Global Enables 22.2 App 2Fh x 
Clear Message Flags 22.3 App 30h S s s s 
Get Message Flags 22.4 App 31h s s s S 
Enable Message Channel Receive 22.5 App 32h S s S s 
Get Message 22.6 App 33h S S S s 
Send Message 22.7 App 34h x? x 
Read Event Message Buffer 22.8 App 35h Ss s s s 
Get BT Interface Capabilities 22.10 App 36h x 
Get System GUID 22.14 App 37h på | på på på 
Set System Info Parameters 22.14a App 58h x 
Get System Info Parameters 22.14b App 59h x 
Get Channel Authentication Capabilities 22.13 App 38h på | på på på 
Get Session Challenge 22.15 App 39h på | på på | på 
Activate Session 22.17 App 3Ah på | på på på 
Set Session Privilege Level 22.18 App 3Bh Lä 
Close Session 22.19 App 3Ch xé 
Get Session Info 22.20 App 3Dh x 
unassigned - App 3Eh - z g - 
Get AuthCode 22.21 App 3Fh x 
Set Channel Access 22.22 App 40h x 
Get Channel Access 22.23 App 41h x 
Get Channel Info Command 22.24 App 42h x 
Set User Access Command 22.26 App 43h x 
Get User Access Command 22.27 App 44h x 
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section NetFn CMD U (0) A 
Set User Name 22.28 App 45h X 
Get User Name Command 22.29 App 46h x 
Set User Password Command 22.30 App 47h x 
Activate Payload 24.1 App 48h [10] | [10] | [10] 
Deactivate Payload 24.2 App 49h [10] | [10] | [10] 
Get Payload Activation Status 24.4 App 4Ah x 
Get Payload Instance Info 24.5 App 4Bh x 
Set User Payload Access 24.6 App 4Ch x 
Get User Payload Access 24.7 App 4Dh x 
Get Channel Payload Support 24.8 App 4Eh x 
Get Channel Payload Version 24.9 App 4Fh x 
Get Channel OEM Payload Info 24.10 App 50h x 
unassigned - App 51h - - - 
Master Write-Read 22.11 App 52h x 
unassigned 4 App 53h s + = 
Get Channel Cipher Suites 22.15 App 54h p p p 
Suspend/Resume Payload Encryption 24.3 App 55h x? 
Set Channel Security Keys 2225 App 56h x 
Get System Interface Capabilities 22.9 App 57h x 
unassigned e App 58h-5Fh = = 
Firmware Firewall Configuration (see IPM * App 60h-64h * “ = 
Device Commands, above) 
Chassis Device Commands 
Get Chassis Capabilities 28.1 Chassis 00h x 
Get Chassis Status 28.2 Chassis Oth x 
Chassis Control 28.3 Chassis 02h x 
Chassis Reset 28.4 Chassis 03h x 
Chassis Identify 28.5 Chassis 04h x 
Set Front Panel Button Enables 28.6 Chassis OAh X 
Set Chassis Capabilities 28.7 Chassis 05h X 
Set Power Restore Policy 28.8 Chassis 06h x 
Set Power Cycle Interval 28.9 Chassis 0Bh x 
Get System Restart Cause 28.11 Chassis 07h x 
Set System Boot Options 28.12 Chassis 08h X6 
Get System Boot Options 28.13 Chassis 09h x 
unassigned - Chassis OCh-OEh - - - 
Get POH Counter 28.14 Chassis OFh X 
Event Commands 
Set Event Receiver 29.1 S/E 00h x 
Get Event Receiver 29.2 S/E Oth X 
Platform Event (a.k.a. "Event Message”) 29.3 S/E 02h X 
unassigned - S/E 03h- - - - 

OFh 

PEF and Alerting Commands 
Get PEF Capabilities 30.1 S/E 10h x 
Arm PEF Postpone Timer 30.2 S/E 11h X 
Set PEF Configuration Parameters 30.3 S/E 12h x 
Get PEF Configuration Parameters 30.4 S/E 13h x 
Set Last Processed Event ID 30.5 S/E 14h X 
Get Last Processed Event ID 30.6 S/E 15h X 
Alert Immediate 30.7 S/E 16h X 
PET Acknowledge 30.8 S/E 17h p p p 


Sensor Device Commands 
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section NetFn CMD C U (0) A 
Get Device SDR Info 35.2 S/E 20h | | | | 
Get Device SDR 35.3 S/E 21h | | | | 
Reserve Device SDR Repository 35.4 S/E 22h | | | | 
Get Sensor Reading Factors 35.5 S/E 23h x 
Set Sensor Hysteresis 35.6 S/E 24h x 
Get Sensor Hysteresis 35.7 S/E 25h x 
Set Sensor Threshold 35.8 S/E 26h x 
Get Sensor Threshold 35.9 S/E 27h x 
Set Sensor Event Enable 35.10 S/E 28h x 
Get Sensor Event Enable 35.11 S/E 29h x 
Re-arm Sensor Events 35.12 S/E 2Ah X 
Get Sensor Event Status 35.13 S/E 2Bh x 
Get Sensor Reading 35.14 S/E 2Dh x 
Set Sensor Type 35.15 S/E 2Eh x 
Get Sensor Type 35.16 S/E 2Fh x 
Set Sensor Reading And Event Status 35.17 S/E 30h x 
FRU Device Commands 
Get FRU Inventory Area Info 34.1 Storage 10h x 
Read FRU Data 34.2 Storage 11h x 
Write FRU Data 34.3 Storage 12h x 
SDR Device Commands 
Get SDR Repository Info 33.9 Storage 20h x 
Get SDR Repository Allocation Info 33.10 Storage 21h x 
Reserve SDR Repository 33.11 Storage 22h x 
Get SDR 33.12 Storage 23h x 
Add SDR 33.13 Storage 24h x 
Partial Add SDR 33.14 Storage 25h x 
Delete SDR 33.15 Storage 26h x 
Clear SDR Repository 33.16 Storage 27h x 
Get SDR Repository Time 33.17 Storage 28h x 
Set SDR Repository Time 33.18 Storage 29h x 
Enter SDR Repository Update Mode 33.19 Storage 2Ah x 
Exit SDR Repository Update Mode 33.20 Storage 2Bh x 
Run Initialization Agent 33.21 Storage 2Ch x 
SEL Device Commands 
Get SEL Info 31.2 Storage 40h x 
Get SEL Allocation Info 31.3 Storage 41h x 
Reserve SEL 31.4 Storage 42h x 
Get SEL Entry 31.5 Storage 43h x 
Add SEL Entry 31.6 Storage 44h x 
Partial Add SEL Entry 31.7 Storage 45h x 
Delete SEL Entry 31.8 Storage 46h x 
Clear SEL 31.9 Storage 47h x 
Get SEL Time 31.10 Storage 48h x 
Set SEL Time 31.11 Storage 49h x 
Get Auxiliary Log Status 31.12 Storage 5Ah x 
Set Auxiliary Log Status 31.13 Storage 5Bh x 
Get SEL Time UTC Offset 31.11a Storage 5Ch x 
Set SEL Time UTC Offset 31.11b Storage 5Dh x 
LAN Device Commands 
Set LAN Configuration Parameters 23.1 Transport Oth X 
Get LAN Configuration Parameters 23.2 Transport 02h X 
Suspend BMC ARPs 23.3 Transport 03h x 
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section NetFn CMD C U (0) A 
Get IP/UDP/RMCP Statistics 23.4 Transport 04h x 
Serial/Modem Device Commands 
Set Serial/Modem Configuration 25.1 Transport 10h x 
Get Serial/Modem Configuration 25.2 Transport 11h x 
Set Serial/Modem Mux 25.3 Transport 12h x 
Get TAP Response Codes 25.4 Transport 13h x 
Set PPP UDP Proxy Transmit Data 25.5 Transport 14h s s s s 
Get PPP UDP Proxy Transmit Data 25.6 Transport 15h Ss s s s 
Send PPP UDP Proxy Packet 25.7 Transport 16h s s s s 
Get PPP UDP Proxy Receive Data 25.8 Transport 17h s s s s 
Serial/Modem Connection Active 25.9 Transport 18h b b b b 
Callback 25.10 Transport 19h [7] x 
Set User Callback Options 25.11 Transport 1Ah x 
Get User Callback Options 25.12 Transport 1Bh x 
Set Serial Routing Mux 2513 Transport 1Ch X 
SOL Activating 26.1 Transport 20h be | b2 b2 | b2 
Set SOL Configuration Parameters 26.2 Transport 21h x 
Get SOL Configuration Parameters 26.3 Transport 22h x 
Command Forwarding Commands 
Forwarded Command 35b.4 Transport 30h b3 | b3 b3 b3 
Set Forwarded Commands 35b.1 Transport 31h x 
Get Forwarded Commands 35b.2 Transport 32h x 
Enable Forwarded Commands 35b.3 Transport 33h x 
Bridge Management Commands (ICMB) 
Get Bridge State [ICMB] Bridge OOh x 
Set Bridge State [ICMB] Bridge Oth x 
Get ICMB Address [ICMB] Bridge 02h x 
Set ICMB Address [ICMB] Bridge 03h x 
Set Bridge ProxyAddress [ICMB] Bridge 04h x 
Get Bridge Statistics [ICMB] Bridge 05h x 
Get ICMB Capabilities [ICMB] Bridge 06h x 
Clear Bridge Statistics [ICMB] Bridge 08h x 
Get Bridge Proxy Address [ICMB] Bridge 09h x 
Get ICMB Connector Info [ICMB] Bridge OAh x 
Get ICMB Connection ID [ICMB] Bridge OBh x 
Send ICMB Connection ID [ICMB] Bridge OCh x 
Discovery Commands (ICMB) 
PrepareForDiscovery [ICMB] Bridge 10h x 
GetAddresses [ICMB] Bridge 11h x 
SetDiscovered [ICMB] Bridge 12h x 
GetChassisDeviceld [ICMB] Bridge 13h X 
SetChassisDeviceld [ICMB] Bridge 14h x 
Bridging Commands (ICMB)I! 
BridgeRequest [ICMB] Bridge 20h x 
BridgeMessage [ICMB] Bridge 21h x 
Event Commands (ICMB) ®! 
GetEventCount [ICMB] Bridge 30h x 
SetEventDestination [ICMB] Bridge 31h x 
SetEventReceptionState [ICMB] Bridge 32h x 
SendICMBEventMessage [ICMB] Bridge 33h X 
GetEventDestination (optional) [ICMB] Bridge 34h x 
GetEventReceptionState (optional) [ICMB] Bridge 35h x 


OEM Commands for Bridge NetFn 
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section NetFn CMD C U (0) A 
OEM Commands [ICMB] Bridge COh-FEh - - - - 


Other Bridge Commands 


Error Report (optional) [ICMB] Bridge FFh x 


1. This command is sent using the Broadcast format on IPMB. See command description for details. 

2. A User can use a Send Message command to deliver a message to system software, but 
Operator privilege is required to use it to access other channels. 

3. Command only applies to authenticated channels. 

4. This is effectively a no-op if the user has a maximum privilege limit of User since the command 
could not be used to change the operating privilege level to a higher value. 

5. A session operating at Callback, User, or Operator can only use this command to terminate their 

own session. An Administrator or system software can use the command to terminate any 

session. 

There is a bit in this command that can only be set at Administrator privilege level. 

Command available for all levels except for User level 

See [ICMB] specification for command specifications. 

The Suspend/Resume Payload Encryption command may be overridden by a configuration 

option for the particular payload type that forces encryption to be used. In this case, an Admin 

level command would typically be required to change the configuration. 

10. The configuration parameters for a given payload type determine the privilege level required to 
activate / deactivate the payload. 
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Appendix H - Sub-function Assignments 


The following table lists the sub-function numbers associated with individual commands (if any). These numbers are 
used with the “Firmware Firewall” configuration and command discovery commands. 


Table H-1, Sub-function Number Assignments 


Sub 
Fn # NetFn CMD 

IPM Device “Global” Commands 
reserved App 00h 
Get Device ID App Oth 
Broadcast ‘Get Device ID! App 01h 
Cold Reset App 02h 
Warm Reset App 03h 
Get Self Test Results App 04h 
Manufacturing Test On App 05h 
Set ACPI Power State App 06h 
Get ACPI Power State App 07h 
Get Device GUID App 08h 
reserved App 09h-OFh 
Set Command Enables App 60h 
Get Command Enables App 61h 
Set Command Sub-function Enables App 62h 
Get Command Sub-function Enables App 63h 
Get OEM NetFn IANA Support App 64h 
BMC Watchdog Timer Commands 
Reset Watchdog Timer App 22h 
Set Watchdog Timer App 24h 

Set Timer Use Field 0 

Set Timer Actions 1 

Clear Timer Use Expiration Flags 2 

Set Countdown value 3 
Get Watchdog Timer App 25h 
BMC Device and Messaging Commands 
Set BMC Global Enables App 2Eh 

Change message queue interrupt enable 0 

Change event message buffer full interrupt enable 1 

Change event message buffer enable 2 

Change System Event Logging enable 3 

reserved / unspecified s 

Change OEM 0 enable 5 

Change OEM 1 enable 6 

Change OEM 2 enable 7 
Get BMC Global Enables App 2Fh 
Clear Message Flags App 30h 

Receive Message Queue clear 0 

Event Message Buffer clear 1 

reserved / unspecified 2 

Watchdog pre-timeout interrupt clear 3 

reserved / unspecified 4 

OEM 0 clear 5 

OEM 1 clear 6 

OEM 2 clear 7 
Get Message Flags App 31h 
Enable Message Channel Receive App 32h 
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reserved / unspecified 
Channel 1 enable/disable 
Channel 2 enable/disable 
Channel 3 enable/disable 
Channel 4 enable/disable 
Channel 5 enable/disable 
Channel 6 enable/disable 
Channel 7 enable/disable 
Channel 8 enable/disable 
Channel 9 enable/disable 
Channel Ah enable/disable 
Channel Bh enable/disable 


Sub 
Fn ff NetFn CMD 


OO ONOU P ob — CH 


ak sch 
ad O 


Gei Message 


App 33h 


Send Message 
Send to channel 0 
Send to channel 1 
Send to channel 2 
Send to channel 3 
Send to channel 4 
Send to channel 5 
Send to channel 6 
Send to channel 7 
Send to channel 8 
Send to channel 9 
Send to channel Ah 
Send to channel Bh 


App 34h 


OO ONOU  POD—O 


aks dk 
== O 


Read Event Message Buffer 


App 35h 


Get BT Interface Capabilities 


App 36h 


Get System GUID 


App 37h 


Get Channel Authentication Capabilities 


App 38h 


Get Session Challenge 


App 39h 


Activate Session 


App 3Ah 


Set Session Privilege Level 


App 3Bh 


Close Session 
reserved / unspecified 
Close Channel 1 
Close Channel 2 
Close Channel 3 
Close Channel 4 
Close Channel 5 
Close Channel 6 
Close Channel 7 
Close Channel 8 
Close Channel 9 
Close Channel Ah 
Close Channel Bh 


App 3Ch 


OO ONOU POD—O 


sk eds 
AO 


Get Session Info 


App 3Dh 


unassigned 


App 3Eh 


Get AuthCode 


App 3Fh 


Set Channel Access 
Change configuration for channel 0 
Change configuration for channel 1 
Change configuration for channel 2 
Change configuration for channel 3 


App 40h 


GO PD AO 
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Fn # NetFn CMD 
Change configuration for channel 4 4 
Change configuration for channel 5 5 
Change configuration for channel 6 6 
Change configuration for channel 7 7 
Change configuration for channel 8 8 
Change configuration for channel 9 g 


Change configuration for channel Ah 10 
Change configuration for channel Bh 11 
Get Channel Access App 41h 
Get Channel Info Command App 42h 
Set User Access Command App 43h 
Get User Access Command App 44h 
Set User Name App 45h 
Get User Name Command App 46h 
Set User Password Command App 47h 
Activate Payload App 48h 
Deactivate Payload App 49h 
Get Payload Activation Status App 4Ah 
Get Payload Instance Info App 4Bh 
Set User Payload Access App 4Ch 
Get User Payload Access App 4Dh 
Get Channel Payload Support App 4Eh 
Get Channel Payload Version App 4Fh 
Get Channel OEM Payload Info App 50h 
unassigned App 51h 
Master Write-Read App 52h 


reserved / unspecified 

Access to public bus, channel 1 
Access to public bus, channel 2 
Access to public bus, channel 3 
Access to public bus, channel 4 
Access to public bus, channel 5 
Access to public bus, channel 6 
Access to public bus, channel 7 
Access to private bus 0 

Access to private bus 1 

Access to private bus 2 

Access to private bus 3 

Access to private bus 4 

Access to private bus 5 

Access to private bus 6 

Access to private bus 7 

Access to public bus, channel 8 
Access to public bus, channel 9 
Access to public bus, channel Ah 
Access to public bus, channel Bh 


OEoeAOOAORERNROP DADDY RUIM —OD 


unassigned App 53h 
Get Channel Cipher Suites App 54h 
Suspend/Resume Payload Encryption App 55h 
Set Channel Security Keys App 56h 
Get System Interface Capabilities App 57h 
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Sub 
Fn # NetFn CMD 
Set System Info App 58h 
Get System Info App 59h 
Chassis Device Commands 
Get Chassis Capabilities Chassis 00h 
Get Chassis Status Chassis Oth 
Chassis Control Chassis 02h 
reserved / unspecified 0 
power up 1 
power cycle 2 
hard reset 3 
pulse diagnostic interrupt 4 
initiate soft shutdown via overtemp 5 
Chassis Reset Chassis 03h 
Chassis Identify Chassis 04h 
Force On Indefinitely 0 
Set Front Panel Button Enables Chassis OAh 
Power off via front panel 0 
Reset via front panel 1 
Diagnostic Interrupt via front panel 2 
Standby (sleep) via front panel 3 
Set Chassis Capabilities Chassis 05h 
Set Power Restore Policy Chassis 06h 
Set Power Cycle Interval Chassis 0Bh 
Get System Restart Cause Chassis 07h 
Set System Boot Options Chassis 08h 
reserved / unspecified 0 
Write parameter 1 (service partition selector) 1 
Write parameter 2 (service partition scan) 2 
Write parameter 3 (‘valid bit’ clearing) 3 
Write parameter 4 (boot info acknowledge) [also see sub functions 4 
8 through 12 for add’l modifiers ] 
Write parameter 5 (boot flags) 5 
Write parameter 6 (initiator info) 6 
Write parameter 7 (initiator mailbox) Få 
Write “OEM has handled boot info” bit 8 
Write “SMS has handled boot info.” bit 9 
Write “OS / service partition has handled boot info.” bit. 10 
Write “OS Loader has handled boot info.” bit. 11 
Write “BIOS/POST has handled boot info.” bit. 12 
Get System Boot Options Chassis 09h 
unassigned Chassis OCh-OEh 
Get POH Counter Chassis OFh 
Event Commands 
Set Event Receiver S/E OOh 
Get Event Receiver S/E Oth 
Platform Event (a.k.a. “Event Message”) S/E 02h 
unassigned S/E 03h- 
OFh 
PEF and Alerting Commands 
Get PEF Capabilities S/E 10h 
Arm PEF Postpone Timer S/E 11h 
Disable Postpone Timer 0 
Arm Timer 1 
Temporary PEF disable 2 
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Sub 
Fn # NetFn CMD 

Set PEF Configuration Parameters S/E 12h 

Write parameter 1 (PEF control) 0 

Write parameter 2 (PEF Action global control ) 1 

Write parameter 3 (PEF Startup Delay) 2 

Write parameter 4 (PEF Alert Startup Delay) 3 

Write parameter 6 (Event Filter Table) 4 

Write parameter 7 (Event Filter Table Data 1) 5 

Write parameter 9 (Alert Policy Table) 6 

Write parameter 10 (System GUID) 7 

Write parameter 12 (Alert String Keys) - volatile 8 

Write parameter 12 (Alert String Keys) - non-volatile 9 

Write parameter 13 (Alert Strings) - volatile 10 

Write parameter 13 (Alert Strings) - non-volatile 11 

Write parameter 15 (Group Control Table) - non-volatile 12 

Write OEM parameters 13 
Get PEF Configuration Parameters S/E 13h 
Set Last Processed Event ID S/E 14h 
Get Last Processed Event ID SIE 15h 
Alert Immediate S/E 16h 

reserved / unspecified 0 

Alert to Channel 1 1 

Alert to Channel 2 2 

Alert to Channel 3 3 

Alert to Channel 4 4 

Alert to Channel 5 5 

Alert to Channel 6 6 

Alert to Channel 7 7 

Platform Event Parameters 8 

Alert to Channel 8 9 

Alert to Channel 9 10 

Alert to Channel Ah 11 

Alert to Channel Bh 12 
PET Acknowledge S/E 17h 
Sensor Device Commands 
Get Device SDR Info S/E 20h 
Get Device SDR SE 21h 
Reserve Device SDR Repository S/E 22h 
Get Sensor Reading Factors S/E 23h 
Set Sensor Hysteresis S/E 24h 
Get Sensor Hysteresis SIE 25h 
Set Sensor Threshold SIE 26h 
Get Sensor Threshold SE 27h 
Set Sensor Event Enable SIE 28h 
Get Sensor Event Enable S/E 29h 
Re-arm Sensor Events S/E 2Ah 
Get Sensor Event Status SIE 2Bh 
Get Sensor Reading SIE 2Dh 
Set Sensor Type S/E 2Eh 
Get Sensor Type S/E 2Fh 
Set Sensor Reading and Event Status S/E 30h 
FRU Device Commands 
Get FRU Inventory Area Info Storage 10h 
Read FRU Data Storage 11h 


596 


Intelligent Platform Management Interface Specification 


Sub 
Fn # NetFn CMD 

Write FRU Data Storage 12h 
SDR Device Commands 
Get SDR Repository Info Storage 20h 
Get SDR Repository Allocation Info Storage 2th 
Reserve SDR Repository Storage 22h 
Get SDR Storage 23h 
Add SDR Storage 24h 
Partial Add SDR Storage 25h 
Delete SDR Storage 26h 
Clear SDR Repository Storage 27h 
Get SDR Repository Time Storage 28h 
Set SDR Repository Time Storage 29h 
Enter SDR Repository Update Mode Storage 2Ah 
Exit SDR Repository Update Mode Storage 2Bh 
Run Initialization Agent Storage 2Ch 
SEL Device Commands 
Get SEL Info Storage 40h 
Get SEL Allocation Info Storage 41h 
Reserve SEL Storage 42h 
Get SEL Entry Storage 43h 
Add SEL Entry Storage 44h 
Partial Add SEL Entry Storage 45h 
Delete SEL Entry Storage 46h 
Clear SEL Storage 47h 
Get SEL Time Storage 48h 
Set SEL Time Storage 49h 
Get Auxiliary Log Status Storage 5Ah 
Set Auxiliary Log Status Storage 5Bh 

Set MCA 0 

Set OEM1 1 

Set OEM2 2 
Get SEL Time UTC Offset Storage 5Ch 
Set SEL Time UTC Offset Storage 5Dh 
LAN Device Commands 
Set LAN Configuration Parameters Transport Oth 

reserved / unspecified 0 

Set for channel 1 1 

Set for channel 2 2 

Set for channel 3 3 

Set for channel 4 4 

Set for channel 5 5 

Set for channel 6 6 

Set for channel 7 7 

The following sub-function enables apply across each channel for 

which ‘Set’ has been enabled: 

Write parameters 3, 4, 6, 7, 12-15 (IP Address, IP Address Source, 8 

Subnet Mask, IPv4 Header Parameters, Default Gateway Address, 

Default Gateway MAC Address, Backup Gateway Address, Backup 

Gateway MAC Address) 

Write parameter 5 (MAC Address) 9 

Write parameters 8, 9 (Primary & Secondary RMCP Port) 10 

Write parameter 10, 11 (Gratuitous ARP control, Gratuitous ARP 11 

interval) 

Write Parameter 16 (Community String) 12 
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Sub 
Fn # NetFn CMD 
Write Parameter 18 (Destination Type) - volatile 13 
Write Parameter 18 (Destination Type) - non-volatile 14 
Write Parameter 19 (Destination Addresses) - volatile 15 
Write Parameter 19 (Destination Addresses) - non-volatile 16 
Write Parameter 20 (802.1q VLAN ID) 17 
Write Parameter 21 (802.1q Priority) 18 
Write Parameter 24 (RMCP+ Messaging Cipher Suite Privilege 19 
Levels) 
Write OEM Parameters 20 
Set for channel 8 21 
Set for channel 9 22 
Set for channel Ah 23 
Set for channel Bh 24 
Write Parameter 25 (Destination Address VLAN TAGs) 25 
Write Parameter 26 (Bad Password Threshold) 26 
Get LAN Configuration Parameters Transport 02h 
Suspend BMC ARPs Transport 03h 
reserved / unspecified 0 
ARP Response for channel 1 1 
ARP Response for channel 2 2 
ARP Response for channel 3 3 
ARP Response for channel 4 4 
ARP Response for channel 5 z 
ARP Response for channel 6 6 
ARP Response for channel 7 7 
reserved / unspecified 8 
Gratuitous ARP for channel 1 9 
Gratuitous ARP for channel 2 10 
Gratuitous ARP for channel 3 11 
Gratuitous ARP for channel 4 12 
Gratuitous ARP for channel 5 13 
Gratuitous ARP for channel 6 14 
Gratuitous ARP for channel 7 15 
ARP Response for channel 8 16 
ARP Response for channel 9 17 
ARP Response for channel Ah 18 
ARP Response for channel Bh 19 
Gratuitous ARP for channel 8h 20 
Gratuitous ARP for channel 9h 21 
Gratuitous ARP for channel Ah 22 
Gratuitous ARP for channel Bh 23 
Get IP/UDP/RMCP Statistics Transport 04h 
Serial/Modem Device Commands 
Set Serial/Modem Configuration Transport 10h 
reserved / unspecified 0 
Set for channel 1 1 
Set for channel 2 2 
Set for channel 3 3 
Set for channel 4 4 
Set for channel 5 5 
Set for channel 6 6 
Set for channel 7 Få 
The following sub-function enables apply across each channel for 
which 'Set' has been enabled: 
Write Parameter 2 (Authentication Type Enables) 8 
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Sub 
Fn # NetFn CMD 
Write Parameter 3 (Connection Mode) 9 
Write Parameters 4 & 6 (Session Inactivity Timeout, Session 10 
Termination) 
Write Parameter 5 (Channel Callback Control) 11 
Write Parameter 7 (IPMI Messaging Comm Settings) 12 
Write Parameter 8 (Mux Switch Control) 13 
Write Parameters 9, 10, 11, 12, & 13 (Modem Ring Time, Modem 14 
Init String, Modem Escape Sequence, Modem Hang-up Sequence, 
Modem Dial Command) 
Write Parameters 14 & 18 (Page Blackout Interval, Call Retry 15 
Interval) 
Write Parameter Community String 15 16 
Write Parameters 17, 19, 21, 23 [Destination Info (volatile), 17 


Destination Comm Settings (volatile), Destination Dial Strings 
(volatile), Destination IP Addresses (volatile)] 

Write Parameters 17, 19, 21, 23 [Destination Info (non-volatile), 18 
Destination Comm Settings (non-volatile), Destination Dial Strings 
(non-volatile), Destination IP Addresses (non-volatile)] 


Write Parameters 25, 26, 27, & 28 (TAP Account, TAP Passwords, 19 
TAP Pager ID Strings, TAP Service Settings) 
Write Parameter 29 (Terminal Mode Configuration) 20 


Write Parameters 30, 33, 35, 36, & 48 (PPP Protocol Options, PPP 21 
Link Authentication, PPP ACCM, PPP Snoop ACCM, PPP Remote 
Console IP Address) 

Write Parameters 31 & 32 (PPP Primary RMCP Port Number, PPP 22 
Secondary RMCP Port Number) 


Write Parameter 34 (CHAP Name) 23 
Write Parameter 45 (PPP UDP Proxy IP Header) 24 
Write Parameters 38-44 - volatile (Account 0) (PPP Account Dial 25 


String Selector, PPP Account IP Addresses / BMC IP Address, PPP 
Account User Names, PPP Account User Domains, PPP Account 
User Passwords, PPP Account Authentication Settings, 

PPP Account Connection Hold Times) 

Write Parameters 38-44 - non-volatile (Account 1) (PPP Account 26 
Dial String Selector, PPP Account IP Addresses / BMC IP Address, 
PPP Account User Names, PPP Account User Domains, PPP 
Account User Passwords, PPP Account Authentication Settings, 
PPP Account Connection Hold Times) 

Write Parameters 38-44 - non-volatile (Accounts 2-n) (PPP Account 27 
Dial String Selector, PPP Account IP Addresses / BMC IP Address, 
PPP Account User Names, PPP Account User Domains, PPP 
Account User Passwords, PPP Account Authentication Settings, 
PPP Account Connection Hold Times) 


Write Parameter 49 (System Phone Number) 28 

Write OEM Parameters 29 

Set for channel 8 30 

Set for channel 9 31 

Set for channel Ah 32 

Set for channel Bh 33 

Write Parameter 54 (Bad Password Threshold) 34 
Get Serial/Modem Configuration Transport 11h 
Set Serial/Modem Mux Transport 12h 


reserved / unspecified 

Function 1h (request switch of mux to system) 
Function 2h (request switch of mux to BMC) 
Function 3h (force switch of mux to system) 


aon — 0 
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Function 4h (force switch of mux to BMC) 

Function 5h (block requests to switch mux to system) 
Function 6h (allow requests to switch mux to system) 
Function 7h (block requests to switch mux to BMC) 
Function 8h (allow requests to switch mux to BMC) 


NetFn 


CMD 


Get TAP Response Codes 


Transport 


13h 


Set PPP UDP Proxy Transmit Data 
reserved / unspecified 
Set for channel 1 
Set for channel 2 
Set for channel 3 
Set for channel 4 
Set for channel 5 
Set for channel 6 
Set for channel 7 
Set for channel 8 
Set for channel 9 
Set for channel Ah 
Set for channel Bh 


OONODOARWNH-O 


zech ak 
-= O 


Transport 


14h 


Get PPP UDP Proxy Transmit Data 


Transport 


15h 


Send PPP UDP Proxy Packet 
reserved / unspecified 
Send for channel 1 
Send for channel 2 
Send for channel 3 
Send for channel 4 
Send for channel 5 
Send for channel 6 
Send for channel 7 
Send for channel 8 
Send for channel 9 
Send for channel Ah 
Send for channel Bh 


OO ONOU POD—O 


ak st: 
sd O 


Transport 


16h 


Get PPP UDP Proxy Receive Data 


Transport 


17h 


Serial/Modem Connection Active 


Transport 


18h 


Callback 

reserved / unspecified 

Callback using channel 1 parameters 
Callback using channel 2 parameters 
Callback using channel 3 parameters 
Callback using channel 4 parameters 
Callback using channel 5 parameters 
Callback using channel 6 parameters 
Callback using channel 7 parameters 
Callback using channel 8 parameters 
Callback using channel 9 parameters 
Callback using channel Ah parameters 
Callback using channel Bh parameters 


OO ONOU ob CH 


— sch 
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Transport 


19h 


Set User Callback Options 
reserved / unspecified 
Set for channel 1 
Set for channel 2 
Set for channel 3 
Set for channel 4 
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Set for channel 5 
Set for channel 6 
Set for channel 7 
Set for channel 8 
Set for channel 9 
Set for channel Ah 
Set for channel Bh 


Sub 
Fn ff 
5 


6 
7 
8 
9 


EE 


0 
1 


NetFn 


CMD 


Get User Callback Options 


Transport 


1Bh 


Set Serial Routing Mux 


Transport 


1Ch 


SOL Activating 


Transport 


20h 


Set SOL Configuration Parameters 
reserved / unspecified 
Set for channel 1 
Set for channel 2 
Set for channel 3 
Set for channel 4 
Set for channel 5 
Set for channel 6 
Set for channel 7 
The following sub-function enables apply across each channel for 
which 'Set' has been enabled: 
Write Parameter 1 (SOL Enable) 
Write Parameter 2 (SOL Authentication) 
Write Parameters 3 & 4 (Character Accumulate Interval & Character 
Send Threshold, SOL Retry) 
Write Parameter 5 (SOL non-volatile bit rate -non-volatile) 
Write Parameter 6 (SOL volatile bit rate -volatile) 
Write Parameter 8 (SOL Payload Port Number) 
Set for channel 8 
Set for channel 9 
Set for channel Ah 
Set for channel Bh 


zl OO P WDM CH 


Transport 


21h 


Get SOL Configuration Parameters 


Transport 


22h 


Forwarded Command (NOTE: This command is a byproduct of the 
Command Forwarding capability being enabled on one or more 
channels and cannot be directly enabled/disabled via Firmware 
Firmwall) 


Transport 


30h 


Set Forwarded Commands 


Transport 


31h 


Get Forwarded Commands 


Transport 


32h 


Enable Forwarded Commands 


Transport 


33h 


Bridge Management Commands (ICMB) 


Get Bridge State 


Bridge 


00h 


Set Bridge State 


Bridge 


Oth 


Get ICMB Address 


Bridge 


02h 


Set ICMB Address 


Bridge 


03h 


Set Bridge ProxyAddress 


Bridge 


04h 


Get Bridge Statistics 


Bridge 


05h 


Get ICMB Capabilities 


Bridge 


06h 


Clear Bridge Statistics 


Bridge 


08h 


Get Bridge Proxy Address 


Bridge 


09h 


Get ICMB Connector Info 


Bridge 


OAh 


Get ICMB Connection ID 


Bridge 


OBh 


Send ICMB Connection ID 


Bridge 


OCh 


Discovery Commands (ICMB) 
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Sub 

Fn # NetFn CMD 
PrepareForDiscovery Bridge 10h 
GetAddresses Bridge 11h 
SetDiscovered Bridge 12h 
GetChassisDeviceld Bridge 13h 
SetChassisDeviceld Bridge 14h 
Bridging Commands (ICMB)!! 
BridgeRequest Bridge 20h 
BridgeMessage Bridge 21h 
Event Commands (ICMB) [8] 
GetEventCount Bridge 30h 
SetEventDestination Bridge 31h 
SetEventReceptionState Bridge 32h 
SendICMBEventMessage Bridge 33h 
GetEventDestination (optional) Bridge 34h 
GetEventReceptionState (optional) Bridge 35h 
OEM Commands for Bridge NetFn 
OEM Commands Bridge COh-FEh 
Other Bridge Commands 
Error Report (optional) Bridge FFh 
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Index 


‘AT’ command set, 203 
‘delimiter’ character, 203 

‘long pause’ sequence, 203 
‘Power supply failed’ event, 17 
‘Redundancy lost’ event, 17 


66 


“(transition to) Active, 498 
“(transition to) Busy, 498 
“(transition to) Idle, 498 


<ENTER> character, 203 


0 
00h Completion Code, 45 


24C02, 16, 17, 490, 549 
24C02-compatible SEEPROMs, 16 


8 
8742 interface, 18, 80 


A 


A/D Converter, 549 

Aborted By Command, 83 

Aborted return value, 97, 98 

Access Mode for IPMI messaging, 302 

ACCM, 176, 177, 190, 360 

ACCM negotiation, 189, 190, 359 

ACCM Negotiation, 360 

ACK/Normal Bit, 126 

ACPI Device Power State, 250, 251, 543 

ACPI System Power State sensor, 9 

Activate Session, 21, 56, 58, 59, 61, 62, 135, 144, 
181, 198, 269, 274, 277, 281, 282, 292, 293, 294, 
295, 296, 298, 558, 587, 593 

Activate Session command, 56, 58, 59, 61, 62, 144, 
188 

Activate Session request, 56, 59, 144, 295 

Activate Session response, 59, 144, 294 

Active Sessions table, 298 

Add SDR, 434, 438, 441, 443, 589, 597 

Add SEL Entry, 419, 421, 424, 425, 589, 597 

Additional Device Support, 244 

Address & Control Field compression, 187 

Address & Control Field Compression, 186, 188 
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Address and Control Field Compression, 187, 188, 
358, 359 

Address and Control fields, 187 

Administrator level privilege, 52 

Administrator privilege level, 52 

Advancing eight-count, 60 

Alert Acknowledge Timeout, 319, 354 

Alert Acknowledge Timeout / Retry Interval, 319 

Alert Immediate, 203, 230, 298, 302, 356, 407, 415, 
588, 596 

Alert Immediate command, 203, 230, 302 

Alert policies, 9, 21 

Alert Policies, 33, 36, 223 

Alert Policy Number, 226 

Alert Policy Table, 223, 225, 226, 229, 230, 231, 232, 
411 

Alert Processing, 33, 231, 232 

Alert Processing after power loss, 231 

Alert Processing Device, 29 

Alert sending device, 20 

Alert Standard Forum, 8, 19 

Alert String Key, 230, 412 

Alert String Keys, 412 

Alert String Selector, 230 

Alert Strings, 193, 203, 223, 230, 237, 408, 412 

Always Available, 51 

Always Available Manageability, 8 

Always Available Mode, 172, 174, 175 

Anonymous login, 53, 201 

Anonymous Login Status field, 53 

Application Device, 28 

Arm PEF Postpone Timer, 407, 408 

ARP Cache expiration, 139 

ARP Requests, 138, 139 

ARP Response, 138, 139, 332 

ARP Responses, 139, 332 

ARP table, 139 

ASCII Escape <ESC> character, 181 

ASF 2.0, 10, 19, 129, 130 

ASF message class, 124 

ASF messages, 20, 126 

ASF Presence Ping message, 127 

ASF Presence Pong Message, 127, 129 

ASF Sensor Devices, 20 

ASP’, 124 

Assertion / Deassertion Masks, 557 

Assertion Event Mask, 499, 524, 530 

Asynch Control Character Map, 186 

Asynchronous communication parameters, 168 

Asynchronous Control Character Mask, 176 

ATN flag, 72, 85 

AuthCode, 56, 133, 144, 188, 269, 282, 283, 285, 
293, 294, 295, 296, 299, 300, 587, 593 

Authentication Code, 56, 282, 293, 294, 295 
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Authentication Protocol, 186 

Authentication protocols, 57 

Authentication Type, 21, 56, 133, 144, 188, 273, 274, 
277, 282, 283, 284, 293, 294, 295, 300, 302, 317, 
347, 348 

Authentication Type Enables, 317, 348 

Authentication Type Support, 317, 347 

Authentication Types, 299, 317, 347, 348 

Authentication_Type, 299 

Automatic alerting, 8 

Automatic recovery, 2 

Autonomous Manageability, 8 

Aux Bus Shunt, 125, 318, 359 

Auxiliary Channel Info, 305 

Auxiliary Firmware Revision, 244 


B 


B_BUSY, 107, 108, 109, 111, 112 

B2H_ATN, 107, 108, 110, 111, 112 

B2H_IRQ, 110 

B2H IRO EN, 110 

B2HI_EN, 108 

Backup Gateway Address, 318 

Backup Gateway MAC Address, 318 

Backward compatibility, 8, 543, 549, 584 

Base Address Modifier, 563, 564, 565 

Baseboard Management Controller, 6, 7, 13, 32, 109, 
110, 218, 562 

Basic Mode, 18, 19, 35, 36, 49, 56, 57, 167, 168, 170, 
171, 176, 177, 179, 180, 181, 194, 275, 277, 294, 
351, 354, 369 

Basic Mode Messaging, 183 

Basic Mode, defined, 18 

BIOS FRB2 timeout, 379 

BIOS Mux Control Override, 397 

BIOS POST timeout, 379 

BIOS Shared Mode Override, 397 

Block Selector, 286, 316, 346, 375, 393, 409, 412 

BMC boot flag valid bit clearing, 392, 394 

BMC buffer size, 187 

BMC Message Bridging, 63 

BMC PPP IP Address Negotiation, 358 

BMC SMS LUN, 63, 72, 196 

BMC to Host Attention, 108 

BMC Watchdog Timer, 379 

MC_HWRST, 110 

MC2HOST, 106, 107, 108, 112 

MC-BT, 105, 110 

MC-generated ARP control, 318 

MC-to-Baseboard switch, 352 

MC-to-SMI Handler communication, 79 

Boot Error, 512 

Boot flags, 20, 24, 198, 392, 396 

Boot info acknowledge, 395, 398 

Boot Info Timestamp, 398 
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II 


Boot initiator info, 398 

Boot initiator mailbox, 398, 399 

Boot Options, 9, 175, 198, 368, 392, 393, 588, 595 
Bridge Device, 29, 75 

Bridged Request parameter bit, 66 
BridgeMessage, 590, 602 

BridgeRequest, 590, 602 

Bridging Support, 35 

Broadcast Get Device ID, 252, 253, 435, 451, 452 
BT BMC to Host Buffer, 107 

BT Host to BMC Buffer, 107 

BT interface, 18, 68, 104, 105, 107, 110 

BT Interface, 68, 104, 105, 106, 111, 280, 587, 593 
BT Interface Event Request Message Format, 106 
BT Interface Event Response Message Format, 106 
BT Interface registers, 106 

BT Interface Write Transfer, 111 

BT System Interface Format, 49 

BT CTRL, 106, 107, 112 

Bus timeout interrupts, 24 

Busy bit, 96, 97 

BUSY bit, 93, 94, 95, 96, 97, 108 


C 


C1h, 44, 45, 46, 101 

Call down list, 21 

Call Retry Interval, 354 

Callback, 167, 370 

Callback Control Protocol, 36, 192 
Callback level privilege, 192 

Callback privilege level, 52 

Callback to a pre-specified number, 193 
Callback to caller-specified number, 193 
Callback to one from a list of numbers, 193 
Callback, defined, 36 

Callback, initiate, 192 

Capabilities commands, 15 

Capabilities Flags, 386, 390 

CBCP, 167, 192, 350, 370, 371, 372 
CBCP Address Type, 193 

CBCP callback, 193, 350 

CBCP Callback, 36 

CBCP callback numbers, 192 

CBCP callback support, 345 

CBCP negotiation, 192 

CBCP Negotiation Options, 350, 371, 372 
CC_SMS_GET_STATUS, 100 
CC_SMS_RD_END, 100 
CC_SMS_RD_NEXT, 100, 101 
CC_SMS_RD_START, 100 
CC_SMS_WR_END, 100 
CC_SMS_WR_NEXT, 100 

CC SMS WR START, 100 
Challenge/response mechanism, 21 
Channel / Destination, 230 
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Channel Callback Control, 350 Completion Code operation, 42 
Channel Medium Type, 49, 305 Completion code rules and guidelines, 45 
Channel Medium Type number, 50 Completion Code values, 43 
Channel Model, 21, 48 Completion Codes, purpose, 45 
Channel number, 21, 26, 48, 49, 64, 256, 257, 259, Configure-ack, 190 
260, 261, 263, 264, 265, 267, 268, 274, 276, 281, Configure-Ack, 185, 186, 190 
283, 290, 305, 366, 373, 385, 521, 528, 541 Configure-nak, 190 
Channel Number, 9, 76, 77, 227, 230, 256, 257, 259, Configure-Nak, 185, 190, 191, 358 
260, 261, 263, 264, 265, 267, 268, 272, 274, 276, Configure-Reject, 185, 191 
283, 290, 300, 306, 308, 310, 341, 342, 343, 344, Configure-Request, 185, 186, 190, 191, 358 
371, 372, 398, 431, 521, 528, 540, 541, 543, 545 Connection Hold Time, 231, 232 
Channel Privilege Level Limit, 303, 304 Connection Mode Auto-detect, 170, 176, 360 
Channel Privilege Limit, 22, 62 Container Entity Device Address, 538 
Channel Protocol Type, 49, 305 Container Entity Device Channel, 538 
CHAP, 57, 186, 191, 193, 359, 361 Container Entity Instance, 538 
CHAP link-level authentication, 191 Container Record Link, 536 
CHAP Name, 359 Control/Status register, 95, 96, 99 
CHAP, configuration class options, 191 Control/Status Register, 93, 95 
Chassis Bridge Device, 75 Core Logic device, 549 
Chassis Bridge Device Address, 386, 390 Correctable Memory Error Logging Disabled, 509 
Chassis Capabilities, 385, 433 Count of currently enabled User IDs, 310 
Chassis Control, 173, 366, 385, 388, 389, 392, 394, Critical events, 217 
588, 595 Critical Events, 24, 217 
Chassis Device, 29, 41, 244, 385, 390, 544, 588, 595 Critical Interrupt, 511 
Chassis FRU Info Device Address, 386, 390 Critical system failure, 172 
Chassis Identify, 385, 389, 588, 595 Cross-platform driver, 85, 86, 91 
Chassis Reset, 385, 588, 595 Current Power State, 387 
Chassis SDR Device Address, 386, 390 
Chassis SEL Device Address, 386, 390 D 


Chassis SM Device Address, 390 

Chassis System Management Device Address, 386 

Cipher Suites, 289 

Class of Message, 126, 127, 128, 129, 133, 188 

Clear Bridge Statistics, 590, 601 

Clear Message Flags command, 85 

Clear Read Pointer, 108 

Clear SDR Repository, 438, 441, 444, 589, 597 

Clear SEL, 414, 419, 422, 423, 427, 589, 597 

Clear Write Pointer, 108 

CLR_RD_PTR, 107, 108, 112 

CLR_WR_PTR, 107, 108 

Cold Reset, 381, 441, 451 

Cold Reset command, 105, 247, 248, 423 

Cold Reset Command, 247 

Combo Management ASIC, 549 

Command Byte, 83, 93, 137, 182 

Command code, 102, 104 

Command interpreter, 40 

Command Register, 81, 83, 91 

Command-specific completion codes, 44, 45, 241, 
276, 278, 303, 304, 307, 313, 345, 346, 370, 381, 
393, 409 

Common commands, 2 

Community String, 235, 318, 353 

Compact sensor record, 521, 528 

Completion Code, 103, 105, 370 


D/A Converter, 549 

D1h, 44, 45 

Data records, 2, 15, 490, 550 

Data Register, 83, 93, 96 

Data to write, 281, 449 

Data_In, 81, 82, 83, 84, 90, 564 

Data_Out, 81, 82, 83, 84, 90, 564 

Deassertion Event Mask, 499, 525, 531 

Default Gateway Address, 318 

Default Gateway MAC Address, 318, 327, 328 

Deferred Alerts, 223 

Delete SDR, 435, 438, 439, 440, 441, 444, 589, 597 

Delete SEL Entry, 414, 419, 423, 426, 589, 597 

Destination Addresses, 320 

Destination Comm Settings, 351, 355 

Destination Dial String, 350, 371, 372 

Destination Dial Strings, 355, 360 

Destination Info, 353 

Destination IP Address, 132, 135, 188, 354, 356, 361, 
368 

Destination IP Addresses, 355, 356 

Destination Port, 128, 129, 132, 135, 188 

Destination Port Number, 368 

Destination Type, 232, 319, 353, 354, 356, 415 

Device Absent/Device Present, 494 

Device Enabled/Disabled, 494 
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Device ID/Device Instance, 245 

Device Locator, 34, 435, 436, 437, 540, 541 

Device relative, 26 

Device Revision, 244, 245, 545 

Device Slave Address, 491 

Device specific completion codes, 44 

Device Type Codes, 544, 549 

Device-specific completion codes, 46 

DHCP, 137, 139, 140, 318 

DHCP lease, 140 

DHCP, resolving issues, 140 

DHCPv6 Timing, 143, 327, 330 

Diagnostic boot completed, 512 

Dial Page, 20, 21, 35, 168, 203, 230, 232, 233, 319, 
353, 354 

Dial Paging, 167, 202, 203 

Dial-out PET Alerting, 167, 202 

Digital sensor, 502 

Direct Connect Mode, 35, 61, 173, 174, 175, 179, 
352 

Discrete Reading Mask, 521, 525, 531 

DMI Usage State, 498, 499 

DMI-based Severity, 500 

Dynamic Sensor Device, 452 


E 


Emergency management, 25, 172, 219 

Enable Baseboard-to-BMC switch on <ESC>(, 349 

Enable Message Channel Receive, 269, 272, 587, 592 

Enable User for Link Authentication bit, 57, 359, 361 

Enter SDR Repository Update Mode, 438, 446 

Enter SDR Update Mode, 434 

Entity, 494 

Entity Association, 17, 26, 34, 494, 495, 496, 522, 
528, 536, 537, 538 

Entity Association Record, 26, 495, 536, 537, 538 

Entity Association records, 34, 550 

Entity Association Records, 17, 495 

Entity ID Codes, 550 

Entity ID field, 550 

Entity Instance, 26, 236, 492, 495, 496, 522, 528, 
532, 536, 537, 538, 539, 540, 541, 544 

Entity Instance Sharing, 532 

Entity Instance value, 26, 236, 492, 496, 551 

Entity Instance value, restrictions, 493 

Entity Presence, 514 

Entity Presence sensor, 494, 495 

Entity, presence, 494 

ERROR STATE, 82, 84, 85 

Event commands, 26 

Event Conditions, 220, 465, 468 

Event Dir, 80, 103, 106, 235, 402, 403, 404, 431, 
498, 502, 555 

Event filter, 28, 33, 232, 233, 510 

Event Filter Action, 226 


IV 


Event Filter Entry, 223 

Event filter table, 21, 223, 225, 229, 231, 408 

Event Filter Table, 225, 234, 411, 596 

Event formats, 2 

Event Generation, 38, 437 

Event Generator, 15, 28, 32, 35, 47, 218, 219, 244, 
419, 544 

Event Generator Device, 28 

Event Logging Disabled, 509 

Event Mask, 227, 499, 522, 524, 525, 529, 530, 531, 
555, 556, 557 

Event Mask Field, 499 

Event Message Buffer, 54, 72, 73, 82, 91, 95, 224, 
225, 237, 269, 270, 271, 272, 278, 305, 402, 547, 
587, 593 

Event Message Buffer Full, 85, 91, 278 

Event Message Buffer Full flag, 85 

Event Message, defined, 15 

Event Message, routing, 15 

Event Messages, 15, 24, 28, 32, 34, 41, 46, 47, 54, 
72, 80, 103, 106, 217, 218, 219, 220, 401, 403, 
419, 431, 438, 458, 459, 460, 461, 463, 465, 468, 
469, 498, 499, 502, 523, 529, 555 

Event Messages, retries, 218 

Event Offset Mask, 227, 228 

Event Receiver, 15, 32, 34, 44, 47, 71, 72, 73, 80, 
103, 106, 217, 218, 219, 244, 269, 401, 402, 403, 
405, 419, 424, 426, 437, 468, 543, 544, 588, 595 

Event Receiver Device, 28, 419 

Event Receiver Slave Address, 401, 402 

Event Request Message, 80, 103, 106, 217, 219, 401, 
402, 403, 404, 405 

Event Request Messages, 54, 219 

Event Response Message, 80, 103, 106, 219, 401, 
403 

Event Severity, 226, 236 

Event Source type, 417 

Event Status, 220, 463, 464, 465, 468, 589, 596 

Event Trigger, 220, 227 

Event/Reading Type Code, 220, 403, 405, 431, 498, 
499, 502, 503, 505, 509, 523, 524, 525, 529, 530, 
531, 555, 557 

Event/Reading Type Code table, 499 

EvMRev, 26, 80, 103, 106, 402, 403, 404, 431 

EVT ATN, 95, 107, 110, 111 

Exit SDR Repository Update Mode, 438, 589, 597 

Extended BMC Messaging Channel Model, 9 

External Event Generation, 35 


F 


Failed hardware unit, 2 

Fail-over, 138 

Fault Status asserted, 513 

FCS, 168, 177, 184, 187, 188, 189, 368 
FFh Completion Code, 46 


Field Programmable Gate Array, 107 

Filter Configuration, 226 

Flag sequence, 188 

Flags register, 93, 94, 96 

Flags Register, 93 

Flags register bits, 94 

Force progress event traps, 397 

FPGA, 18, 107 

Fragment Offset, 132, 188 

Frame check sequence, 184 

Frame Check Sequence, 187 

Frame Type, 132, 135 

Front Panel Lockout, 386, 387, 390, 505 
Front Panel NMI/ Diagnostic Interrupt, 511 
FRU Commands, 32 

FRU Device ID / Device Slave Address, 541 
FRU Device Locator, 490, 491, 493 

FRU device locator record, 495 

FRU Device Locator Record, 541 

FRU Information Interface, 32 

FRU information, accessibility, 16 

FRU information, contents, 16 

FRU Inventory Device, 28, 244, 447, 528, 544, 549 
FRU Inventory Device Info, 34 

FRU Inventory Offset, 448, 449 

Full Sensor Record, 521, 528 


G 


Generator ID, 47, 226, 227, 402, 403, 404, 431 

Generic Completion Codes, 43, 45 

Generic Device Locator Record, 540 

Get ACPI Power State, 243, 251, 587, 592 

Get AuthCode, 296, 300 

Get AuthCode Data, 299 

Get Auxiliary Log Status, 419, 420, 429, 430, 589, 
597 

Get BMC Global Enables, 73, 91, 269, 270, 587, 592 

Get BMC Global Enables command, 73, 91 

Get Bridge Proxy Address, 590, 601 

Get Bridge State, 590, 601 

Get Bridge Statistics, 590, 601 

Get BT Interface Capabilities, 269 

Get BT Interface Capabilities, 280 

Get BT Interface Capabilities command, 106 

Get Channel Access, 172, 173, 269, 304, 307, 586, 
587, 594 

Get Channel Authentication Capabilities, 53, 58, 
135, 170, 171, 188, 269, 281, 282, 283, 352, 417, 
587, 593 

Get Channel Authentication Capabilities command, 
53, 56, 58, 144, 177 

Get Channel Info, 26, 48, 49, 54, 269, 277, 305, 546, 
587, 594 

Get Channel Info command, 49, 62, 64 

Get Channel Info Command, 269, 587, 594 
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Get Channel Sessions command, 398 

Get Chassis Capabilities, 75, 385, 386, 390, 588, 595 

Get Chassis Status, 385, 387, 390, 391, 588, 595 

Get Device GUID, 243, 545, 587, 592 

Get Device ID, 26, 243, 244, 246, 252, 253, 329, 364, 
398, 414, 432, 434, 435, 438, 451, 498, 545, 587, 
592 

Get Device ID command, 246, 432 

Get Device ID Command, 244 

Get Device SDR, 451, 453, 454, 589, 596 

Get Device SDR Info, 451, 452, 589, 596 

Get Event Receiver, 402 

Get Event Status, 464 

Get FRU Inventory Area Info, 447, 448, 589, 596 

Get ICMB Address, 590, 601 

Get ICMB Capabilities, 590, 601 

Get ICMB Connection ID, 590, 601 

Get ICMB Connector Info, 590, 601 

Get IP/UDP/RMCP Statistics, 332, 333, 590, 598 

Get LAN Configuration Parameters, 315, 589, 598 

Get Last Processed Event ID, 224, 407, 408, 415, 
588, 596 

Get Message command, 63, 64, 72, 73, 75, 76, 102, 
273, 368 

Get Message Flags, 64, 82, 84, 85, 86, 269, 271, 278, 
381, 587, 592 

Get Message Flags command, 64, 82, 85, 86, 91 

Get Message Flags commands, 84 

Get Message Response, 76, 576 

Get parameter revision only, 286, 316, 346, 375, 409 

Get PEF Capabilities, 407, 588, 595 

Get PEF Configuration Parameters, 407, 409, 588, 
596 

Get POH Counter, 385, 399, 588, 595 

Get PPP UDP Proxy Receive Data, 345, 368, 369, 
590, 600 

Get PPP UDP Proxy Transmit Data, 345, 367, 590, 
600 

Get SDR, 244, 421, 434, 435, 436, 437, 438, 439, 
441, 442, 443, 445, 453, 589, 597 

Get SDR Repository Allocation Info, 438, 440, 589, 
597 

Get SDR Repository Info, 421, 434, 436, 438, 439, 
441, 589, 597 

Get SDR Repository Time, 438, 445, 446 

Get SEL Allocation Info, 419, 422, 589, 597 

Get SEL Entry, 419, 423, 424, 589, 597 

Get SEL Info, 419, 421, 439, 589, 597 

Get SEL Time, 398, 419, 427, 445, 446, 589, 597 

Get Self Test Results, 23, 248, 451, 587, 592 

Get Self Test Results command, 248 

Get Sensor Event Enable, 451, 460, 589, 596 

Get Sensor Event Status, 220, 221, 401, 451, 461, 
463, 464, 465 

Get Sensor Event Status command, 220 

Get Sensor Hysteresis, 451, 456, 589, 596 
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Get Sensor Reading, 14, 220, 221, 401, 451, 461, 
463, 464, 465, 467, 468, 471, 484, 494, 502, 521, 
524, 525, 530, 531, 555, 557, 589, 596 

Get Sensor Reading Factors, 455, 482, 483 

Get Sensor Threshold, 589, 596 

Get Sensor Thresholds, 457, 525, 531 

Get Sensor Type, 451, 467, 469, 589, 596 

Get Serial/Modem Configuration, 345, 346, 590, 599 

Get Session Challenge, 21, 58, 59, 61, 62, 135, 144, 
181, 188, 269, 281, 282, 292, 293, 294, 295, 587, 
593 

Get Session Challenge command, 56, 58, 61, 135, 
189, 192 

Get Session Challenge/Activate Session command, 
194 

Get Session Info, 62, 269, 297, 298, 368, 586, 587, 
593 

Get Status/Abort control code, 85 

Get Status/Abort transaction, 84 

Get System Boot Options, 198, 385, 393 

Get System GUID, 135, 188, 269, 281, 285, 411, 587, 
593 

Get System Restart Cause, 385, 392, 588, 595 

Get TAP Response Codes, 345, 367 

Get User Access, 269, 309, 310, 586, 587, 594 

Get User Access Command, 269, 309, 587, 594 

Get User Callback Options, 345, 372, 590, 601 

Get User Name Command, 269, 311, 588, 594 

Get Watchdog Timer, 379, 380, 381, 383 

GET_BT_INTERFACE CAPABILITIES, 107 

GET_STATUS, 83, 84, 90, 91, 96 

GET_STATUS / ABORT, 83 

Get_Status control code, 82 

GET_STATUS/ABORT, 84, 90, 91 

GET_STATUS/ABORT control code, 83 

GetAddresses, 590, 602 

GetChassisDeviceld, 590, 602 

GetEventCount, 590, 602 

GetEventDestination, 590, 602 

GetEventReceptionState, 590, 602 

Global commands, 28 

Gratuitous ARP, 138, 139, 315, 318, 331, 332 

Gratuitous ARP interval, 318 

Gratuitous ARP Response, 332 

Gratuitous ARP suspend, 332 


H 


H_BUSY, 107, 108, 111, 112 

H2B_ATN, 104, 107, 108, 111, 112 

Handshake character, 183 

Hard reset, 54, 82, 199, 352, 365, 379, 383, 388, 389, 
399, 436, 512 

Hardware component restrictions, 23 

Hardware handshake, 176 

Header Checksum, 132, 188 


VI 


Header Length, 132, 188 

Highest Received, 558 

High-going threshold, 464, 465 

Host BT interface, 107 

Host Busy, 108 

Host to BMC Attention, 108 
HOST2BMC, 106, 107 

HOST2BMC buffer, 106, 107, 108, 111 
Hot-plug slot status, 9 


I 


DC Master Write/Read, 26 

IANA, 42, 126, 128, 129, 200, 237, 244, 305, 317, 
347, 429, 430 

IANA Enterprise ID Number, 398 

IANA enterprise number, 128, 129, 284 

IANA Enterprise Number, 305 

IANA OEM ID, 283, 317, 348 

ICMB Bridge Controller, implementing, 75 

ICMB Bridge Device, implementation options, 75 

Identify Status asserted, 513 

IDLE_STATE, 82, 84, 85 

IDLE_STATE OBF interrupt, 92 

IDLE STATE OBF interrupt, 86 

Illegal Control Code, 83 

Illegal Date Field, 349 

Inbound Session Sequence Number, 59, 60 

Initial inbound seq#, 295 

Initialization Agent, 15, 34, 433, 436, 446, 469, 522, 
529, 543 

Initialization Agent steps, 437 

Initialization Agent, requirements, 436 

Initialization required field, 16 

Intelligent Battery controller, 549 

Intelligent Platform Management device, 28 

Intelligent Platform Management, defined, 12 

Intelligent Platform Management, key characteristics, 
12 

Interface circuitry, 106 

Internal Event Generation, 35 

INTMASK, 106, 108, 110 

Invalid Command, 44, 45, 46 

Inventory information, 2 

IP Address Assignment, 190, 191, 358 

IP Address of remote console, 298 

IP Address Source, 318 

IP Address, lost, 140 

IP Control Protocol, 190 

IP Header, 132, 135, 168, 188, 318 

IP Packets Received, 333 

IP Packets Transmitted, 333 

IPCP, 171, 177, 179, 190, 191, 360 

IPCP Configure-Request, 190, 191, 358 

IPCP Negotiation, 362 

IPCP option 1, 191 


IPCP option 2, 191 

IPCP option 3, 190, 191 

IPCP Terminate-Request, 191 

IPM Device, 28, 34, 438, 587, 592 

IPM Device commands, 28, 38, 243 

IPM Device support, 244 

IPMB Event Receiver, 32 

IPMB Interface, 32, 34, 71 

IPMB message, restrictions, 72 

IPMB Seq field, 219 

IPMB, defined, 13 

IPMI Challenge-Response, 58 

IPMI managed systems discovery, 124 

IPMI message class, 124 

IPMI Message Length, 134, 187, 188 

IPMI messaging, 167 

IPMI Messaging Comm Settings, 351 

IPMI Messaging streams, 21 

IPMI over LAN, 19, 132, 167 

IPMI serial/modem messages, 131 

IPMI-over-LAN, 124, 126 

IPv4 protocol, 191 

IPv4 Protocol Packets, 191 

IPv6, 123, 127, 135, 140, 141, 142, 320, 323, 324, 
325, 326, 327, 328, 329 


K 


KCS communication interrupts, 84 

KCS interface, 18, 79, 83, 84, 85, 91, 93, 564 
KCS Interface, 79, 80, 84, 90 

KCS interface addresses, 81 

KCS interface control codes, 83 

KCS Interface control codes, 81 

KCS Interface host software, 82 

KCS Interface message transfers, 83 

KCS Interface registers, 80, 81 

KCS Interface state bits, 82 

KCS Interface status codes, 83 

KCS non-communication interrupts, 84, 91 
KCS System Interface Format, 49 
Keyboard Controller Style, 18, 79, 80, 563 


L 


LAN Alert Format, 20 

LAN Alerting, 20, 35, 124, 137, 319, 351 
LAN Alerts, 20, 137, 229 

LAN channel, 21 

LAN Channel, 144 

LAN Configuration Parameters, 140, 285, 286, 315, 
316, 332, 375, 376, 589, 597 

LAN Controller, 123 

LAN interface, 14, 19, 69, 123 

LAN Interface, 33, 123 

LAN Messaging, 35 

LAN Messaging and Alerting, 9 
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LAN/PPP Input, 69 

LAN/PPP Output, 69 

LAN-based interface, 23 

Language Code, 236 

Last BMC Processed Event, 224, 415 
Last BMC Processed Record ID, 231, 233 
Last BMC-processed Event, 224 

Last Power Event, 387 

Last Software Processed Event, 224 
Layered Management Value, 7, 8 

LCD controller, 549 

LCP Fields, 185 

LCP Packets, 187 

Linear sensors, 482 

Linear/Linearizable Sensors, 482 

Link Authentication, 57, 191, 359, 361 
Link Authentication protocol, 57 

Lock Sleep Button, 397 

Logical entity, 495, 496, 550 

Logical management devices, 28 

Logical Unit Number, 6, 79, 80, 102, 103, 104, 105 
Low-going threshold, 464, 465 

Is-bit, 187, 360 

LUN 00b, 32, 65, 71, 72, 79, 102, 194, 241, 275, 490, 
541, 544, 586 

LUN 00b, defined, 71 

LUN Olb, defined, 71 

Lun 10b, 72 

LUN 10b, 63, 64, 65, 72, 79, 194, 196, 273, 275, 276 
LUN 10b, defined, 71 

LUN 1 1b, defined, 71 


M 


MAC Address, 137, 138, 298, 318, 320, 321, 327, 
328 

Magic Number, 186 

Management Controller Confirmation Record, 545 

Management Controller Device Locator Record, 543 

Management Subsystem Health, 26 

Manual recovery, 2 

Manufacturer ID, 42, 237, 244, 245, 246, 329, 364, 
398, 414, 432, 498, 503, 545, 548 

Manufacturing Test Mode On, 451 

Master Write/Read, 26 

Master Write-Read, 32, 46, 67, 68, 69, 71, 269, 281, 
490, 491, 540, 541, 576, 577, 586, 588, 594 

Master Write-Read command, 67, 68, 71, 541 

Master Write-Read message, 69 

Maximum number of User IDs, 310 

Maximum Receive Unit, 186, 187 

Message Authentication Code, 133, 188 

Message Class, 126 

Message Data field, 274, 276, 277 

Message Handler, 29, 32, 218 

Message Interface, defined, 40 


VII 
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Message transfer control, 95 

Message-digest algorithms, 21, 144 

Messaging Channels, 54 

Misc. Chassis State, 387, 388, 390 

Modal SDR Repository, 434, 438, 439 

Modem Connect Mode, 35, 36 

Modem Dial Command, 353 

Modem Escape Sequence, 178, 353 

Modem Hang Up Sequence, 178 

Modem Hang-up Sequence, 353 

Modem Init String, 178, 353, 355 

Modem Initialization and Hang Up Line, 178 

Modem mode, 176, 350 

Modem Ring Time, 51, 174, 175, 178, 352 

Modem-answering characteristics, 173 

Modified Write Word protocol, 14, 546 

Modularity, 7, 66 

Monitoring elements, 2 

Most Recent Addition, 421, 439 

Multiple management controllers, 13, 14 

Multiple sessions, 21, 55, 56, 62, 184, 281, 282 

Multi-session connection, 56, 57, 144, 282 

Multi-session packets, 56 

Mux switch, 170, 172, 180, 350, 352, 358, 366, 369, 
370 

Mux Switch Configuration, 349 

Mux Switch Control, 350, 352 

Mux switching, 173 


N 


NCP, 190 

Negative-going Threshold Hysteresis, 456, 527, 533 

Negative-going Threshold Hysteresis Value, 456 

Negotiation Configuration, 358 

Negotiation Control, 358 

Neighbor Discovery / SLAAC Timing, 143, 329, 330 

Network control packets, 190 

Network Function, 14, 40, 79, 80, 83, 93, 96, 102, 
103, 104, 105, 182, 241, 243, 269, 315, 345, 379, 
385, 401, 407, 419, 438, 447, 451 

Network Function code, 79, 137 

Network Function Code, 14, 586 

Network Function Codes, 40 

Network Function handler, 40 

Next SEL Record ID, 424 

No Tracking option, 63 

Non-bridging messages, 67 

non-communications interrupt, 84, 85, 86, 92 

Non-communications interrupts, 85, 86 

Non-critical events, 217 

Non-Linear Sensors, 482 

Non-modal SDR Repository, 434, 439 

Number of Alert Destination IP Addresses, 355 

Number of Alert Destinations, 353 

Number of Alert Policy Entries, 411 


VIII 


Number of Alert Strings, 411 

Number of Destinations, 319, 320, 321 
Number of Dial Strings, 355 

Number of Event Filters, 411 

Number of PPP Accounts, 360 

NV Storage Device Address, 562, 564 


(0) 


OBF flag, 79, 83 

OBF interrupt, 85, 86, 92 
OBF-generated interrupt, 84 

OEM auxiliary data, 284 

OEM Commands, 32, 200, 590, 591, 602 
OEM Custom Fields, 237 

OEM Error, 83 

OEM extensions, driver support, 91 
OEM framing extensions, 191 

OEM message class, 124 

OEM Message Data, 126 

OEM Parameters, 329, 364, 398, 414 
OEM Protocol, 49, 546 

OEM Text Commands, 200 

OEM Transfer Stream Control Codes, 99 
OEM Transfer Stream Status Codes, 99 
Operating Privilege Level, 298 
Operator privilege level, 52 

OS Boot, 512 

OS Critical Stop, 512 

OS Load timeout, 379 

OS Watchdog’ timeout, 380 
Out-of-order packets, 60 


P 


PAD byte, 134 

Page Blackout interval, 202 

Page Blackout Interval, 202, 233, 353 

PAP, 57, 186, 359, 361 

Parameter selector, 285, 286, 315, 316, 345, 346, 
356, 375, 393, 409 

Partial Add SDR, 434, 438, 439, 441, 443, 589, 597 

Partial Add SEL Entry, 419, 423, 425, 426 

Password data, 313 

Password protection, 194, 312 

PCI Management Bus Interface, 33, 35 

PCI PERR, 24, 217, 511 

PCI SERR, 24, 511 

PCI Vital Product Data, 16 

PEF Action global control, 410, 596 

PEF Alert Startup Delay, 410, 411, 596 

PEF Alerting Enable/Disable, 302 

PEF control, 410, 596 

PEF Device, 28 

PEF Postpone Timer, 223, 224, 408, 588, 595 

PEF Startup Delay, 224, 410, 411, 596 

Pending bridged requests, 62 


Pending Bridged Response, 65, 66, 67 

Pending Bridged Response table, 66, 67 

Per-Message Authentication, 56, 144 

Per-Message Authentication Disable option, 57 

PET Acknowledge, 20, 407, 417, 588, 596 

PET Specific Trap, 235 

PFC, 186 

Platform Event, 401, 451 

Platform Event Filtering, 7, 9, 21, 33, 35, 36, 202, 
204, 223, 224, 229, 402, 407 

Platform management datagrams, 123 

Platform management, defined, 2 

Plug ‘N Play, 8, 23 

Plug-and-Play, 562 

Point-to-point protocol, 184 

policy number, 223, 226, 229, 230, 233, 234 

Port Address of remote console, 298 

Port Number of remote console, 298 

Positive-going Threshold Hysteresis, 456, 527, 533 

Positive-going Threshold Hysteresis Value, 456 

POST Error sensor, 26 

POST errors, log, 23 

POST Memory Resize, 507 

post-mortem analysis, 24 

power cycle, 22, 24, 29, 33, 225, 226, 231, 232, 379, 
388, 394, 398, 407, 408, 410, 510 

power down, 51, 172, 174, 175, 202, 225, 366, 373, 
387, 388, 399, 407, 408, 410 

Power on/off operations, 2, 168 

Power restore policy support, 391 

Power up, 9, 24, 172, 246, 248, 249, 366, 388, 391, 
392, 394, 398, 399, 512, 522, 529 

PPP ACCM, 360 

PPP Account Authentication Settings, 361 

PPP Account Connection Hold Time, 232 

PPP Account Connection Hold Times, 361 

PPP Account Dial String Selector, 360 

PPP Account Selector, 191 

PPP Account User Domains, 361 

PPP Account User Names, 361 

PPP Account User Passwords, 361 

PPP Alert, 20, 168, 232, 233, 234, 354 

PPP Alerting, 35, 167, 206, 356, 360, 407 

PPP CHAP, 308 

PPP compatibility, 187 

PPP Configure-Request message, 185 

PPP Frame, 184, 187, 188 

PPP IP Address Negotiation, 358 

PPP IPMI-RMCP, 352 

PPP Link authentication, 171, 193 

PPP Link Negotiation request, 176 

PPP Link options, 191 

PPP Mode, 19, 35, 36, 56, 57, 167, 168, 171, 176, 
177, 179, 191, 192, 194, 275, 277, 351, 352, 354, 
359, 369 

PPP Mode Callback, 36, 354 
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PPP Mode, defined, 19 

PPP Protocol Options, 357, 360 

PPP Remote Console IP Address, 362 
PPP Snoop ACCM, 360 

PPP UDP Proxy, 167, 168, 345, 361, 367, 368 
PPP UDP Proxy IP Header data, 361 

PPP UDP Proxy Receive Buffer Size, 361 
PPP UDP Proxy Transmit Buffer Size, 361 
PPP/UDP Mode, 167, 184 

PPP/UDP Proxy Operation, 168 

Pre-boot Access Mode, 51 

Pre-boot only, 51, 172 

Pre-boot Password Violation, 505 
Predictive Failure asserted, 502, 503 
Predictive Failure deasserted, 502, 503 
Predictive Fault, 217 
PrepareForDiscovery, 590, 602 

Presence Ping message, 127, 129, 144 
Pre-timeout Interrupt, 379, 380 

Primary FRU inventory device, 34 
Primary FRU Inventory Device, 28, 38 
Primary RMCP port, 127 

Primary RMCP Port, 125, 144, 318 
Primary RMCP port address, 179 
Primary RMCP Port Numbe, 359 
Primary RMCP Port Number, 318 

Private Bus Controller, 32 

Private Bus Input, 68 

Private Bus Output, 68 

Private Enterprise ID, 244 

Private Enterprise IDs, 237 

Privilege Levels, 22, 52, 587, 592 
Privilege Levels table, 586 

Privilege Limits, 22, 62 

Processor sensor type, 557 

Protocol Field Compression, 186, 187, 358, 359 
Proxy ARP, 139 

Pulse Diagnostic Interrupt, 388 

PXE boot, 512 
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Quality Protocol, 186 
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RAKP, 146, 149, 154, 162 

Raw values, 484, 485, 486, 527 
READ, 82, 83, 84, 90, 95 

Read count, 281 

Read Event Message Buffer command, 72 
Read FRU Data, 34, 448, 589, 596 
Read Message command, 71, 85 
Read Message state, 82 

Read Transfer, 84, 88, 111, 112 
Read_Next, 97 

READ_STATE, 82, 84, 90 
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Reading Mask, 499, 521, 523, 524, 525, 529, 530, 
531,555 

READY status code, 95, 97, 98 

Re-arm, 221, 589, 596 

Re-arm Sensor, 451, 461, 462, 463 

Re-arm Sensor Events, 451, 461, 462, 463 

Re-arm, defined, 7 

Receive Message Available, 272 

Receive Message Available flag, 85 

Receive Message Queue, 53, 56, 63, 64, 71, 72, 73, 
75, 76, 79, 82, 85, 91, 94, 95, 102, 196, 270, 271, 
272, 274, 277, 546, 586 

Receive Message Queue not empty, 95 

Received IP Address Errors, 333 

Received IP Header Errors, 333 

Receiving ACCM, 190 

Record count LS Byte, 439 

Record count MS Byte, 439 

RECORD KEY BYTES, 521, 528, 537, 538, 540, 
541, 543, 545 

Redundancy Degraded, 495, 502 

Redundancy Lost, 502 

Redundancy Regained, 502 

Remote Access Boot control, 391 

Remote console, defined, 48 

Remote Management Card, 16 

Remote Management Control Protocol, 19, 124 

Request and Response Messages, 84 

Request Fixed PPP IP Address, 358 

Request Messages, 28, 40, 71, 79, 80, 102, 103, 104, 
106, 403 

Request/Response identifier, 40, 46 

Request/response protocol, 14 

Requester’s ID, 40, 46, 102, 444 

Request-to-Response interval, 106 

Reservation ID, 44, 422, 424, 426, 427, 440, 441, 
442, 443, 444, 454 

Reservation Restricted, 423, 441 

Reserve Device SDR Repository, 451, 454, 589, 596 

Reserve SDR Repository, 438, 439, 440, 441, 442, 
443, 589, 597 

Reserve SEL, 419, 421, 422, 423, 424, 425, 426, 427, 
589, 597 

reset actions, 225 

Reset Watchdog Timer, 379, 381, 383 

Responder’s ID, 40, 46 

Response Messages, 40, 42, 80, 102, 103, 105 

RMCP, 19, 20, 51, 65, 69, 124, 125, 126, 127, 128, 
129, 131, 134, 139, 170, 177, 179, 181, 187, 188, 
189, 190, 315, 317, 318, 347 

RMCP ACK, 126, 127, 128 

RMCP ACK handling, 128 

RMCP ACK messages, 128 

RMCP ACK operation, 127 

RMCP Acknowledge Messages, 126 

RMCP data, 127 
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RMCP format, 19, 20 

RMCP header, 126, 128, 129 

RMCP Header, 133, 135 

RMCP message, 187 

RMCP message format, 126 

RMCP Message Format, 188 

RMCP message types, 126 

RMCP messages, 125, 127, 128, 134 

RMCP packet, 20, 51, 131, 132 

RMCP Packet, 188 

RMCP Packets, 184 

RMCP Ping message, 127 

RMCP ping response, 283 

RMCP Ping Response, 317, 348 

RMCP Ping/Pong, 51, 125, 144 

RMCP port, 138, 170, 177 

RMCP Port, 358 

RMCP port address, 140, 168, 171 

RMCP ports, 125 

RMCP sequence number, 127, 128, 129, 133 

RMCP Sequence Number, 134, 188 

RMCP traffic, 171 

RMCP, supported interfaces, 128 

RMCP/IPMI Message packets, 191 

RMCP/UDP packet, 187 

RMCP+, 10, 19, 58, 129, 130, 145, 146, 148, 154 

rmtBrXA, 76, 77 

Rollback feature, 286, 316, 346, 375, 393, 409 

rqAddr, 137, 182 

rqLUN, 49, 72, 73, 137, 182, 197, 253, 274, 275, 277 

rqSA, 49, 72, 253, 274, 275, 277 

rqSeq, 49, 72, 73, 76, 137, 182, 195, 197, 253, 274, 
275, 277 

rqSWID, 49, 197, 275, 277 

rsAddr, 137, 182 

rsLUN, 49, 72, 73, 76, 77, 137, 182, 195, 197, 253, 
274, 275, 277 

rsSA, 49, 72, 73, 76, 77, 253, 274, 275, 277 

rsSA slave address, 252 

rsSWID, 49, 197, 275, 277 

Run Initialization Agent, 438, 446, 589, 597 

RX DATA RDY, 95, 96, 97, 98, 100 
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S1 sleep state, 34 
SC_SMS_RD_END, 100, 101 
SC_SMS_RD_NEXT, 100, 101 
SC_SMS_RD_START, 100, 101 
SC_SMS_RDY, 100, 101 
SC_SMS_WR_END, 100, 101 
SC_SMS_WR_NEXT, 100, 101 
SC_SMS_WR_START, 100, 101 
SDR Device, 28, 433, 439, 445, 589, 597 
SDR Repository, 34 

SDR Repository access, 34 


SDR Repository Device, 28, 244, 433, 436, 437, 438, 
441, 444, 445, 447, 544 

SDR Repository Interface, 32 

SDR Repository Update Mode, 434, 438, 446, 589, 
597 

SDR Type 14h, 26, 546 

SDR update, 34, 224, 245, 434 

Secondary RMCP Port, 125, 318 

Secondary RMCP Port Number, 359 

Secure Aux Bus, 125, 318, 359 

SEL access, 34 

SEL Aging, 225 

SEL Device, 28, 244, 269, 419, 421, 423, 424, 425, 
427, 428, 431, 432, 438, 544, 589, 597 

SEL Event Record format, 26 

SEL Interface, 32, 34 

SEL Record Formats, 431 

SEL Record ID, 424, 426 

Send Alert, 225 

Send ICMB Connection ID, 590, 601 

Send Message, 26, 276, 277, 546, 586 

Send Message command, 54, 56, 63, 64, 65, 66, 67, 
71, 72, 75, 76, 77, 79, 102, 194, 196, 197, 273, 
275, 586, 591 

Send Message commands, 63, 75 

Send Message request, 64, 77, 197 

Send Message response, 197 

Send PPP UDP Proxy Packet, 168, 345, 368, 590, 
600 

SendICMBEventMessage, 590, 602 

Sending ACCM, 190 

Sensor and Event Codes, 498 

Sensor Auto Re-arm Support, 523, 529 

Sensor Capabilities, 437, 522, 523, 524, 529, 530 

Sensor commands, 26 

Sensor Data Record format, 520 

Sensor Data Record Repository, 16, 433 

Sensor Data Records, 220 

Sensor Data Records, purpose, 15 

Sensor Device, 20, 28, 236, 244, 417, 451, 453, 482, 
492, 544, 588, 596 

Sensor Event Message Control Support, 522, 523, 
524, 529, 530 

Sensor Event/Reading Type codes, 26 

Sensor Hysteresis Support, 522, 523, 529 

Sensor Initialization, 16, 433, 436, 522, 529 

Sensor Model, 14, 521, 528, 537, 538, 540, 541, 543, 
545, 546, 548 

Sensor Number, 46, 236, 417, 521, 528, 532 

Sensor Owner ID, 46, 47, 521, 528 

Sensor Owner LUN, 521, 528 

Sensor Population Change Indicator, 452 

Sensor Record Sharing, 532 

Sensor scanning bit, 220 

Sensor Specific enumeration, 498 

Sensor Threshold Access Support, 523, 529 
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Sensor Type Code, 431, 498, 555 

Sensor Unit Type Codes, 554 

Sensors, 34 

Sequence Number Allocator, 67 

Sequence number expiration, 64, 67 

Sequence number wrap-around, 60 

Serial messaging, 35 

Serial Messaging with PPP Mode, 35 

Serial Port Sharing, 9, 33, 51, 167, 168, 170, 173, 
175, 177, 345, 352, 417 

Serial Port Switching, 170, 171 

Serial signal lines, 175 

Serial/Modem Callback, 192 

Serial/modem channel, 21, 51, 168, 345 

serial/modem configuration parameters, 57, 168, 170, 
171, 172, 173, 176, 177, 178, 179, 190, 191, 193, 
201, 202, 204, 205, 206, 231, 233, 308, 345, 350, 
371, 372 

Serial/Modem Connection Active, 171, 176, 179, 180, 
181, 192, 201, 345, 352, 354, 369, 590, 600 

Serial/Modem Connection Active message, 171, 179, 
180, 369 

Serial/Modem Connection Active messages, 171, 179, 
180 

Serial/modem interface, 23, 33, 137, 167, 180 

Serial/Modem Messaging and Alerting, 9 

Serial/Modem Ping, 179, 369 

Service partition scan, 394 

Service partition selector, 394 

Service Type, 132, 188 

Session Handle value, 64 

Session header fields, 281, 282 

Session ID, 21, 55, 58, 59, 133, 135, 144, 181, 188, 
293, 294, 295, 297, 298, 368, 398 

Session Inactivity Timeout, 61, 62, 192, 349 

Session Sequence #, 133, 188 

Session Sequence Number, 60, 135, 188 

Session sequence numbers, 59 

Session Sequence Numbers, 59 

Session Termination, 350 

Session, activate, 21 

Session, purpose, 21 

Session-based channels, 21, 50 

Session-less channels, 21, 274, 281 

session-less commands, 130 

Session-less connection, 55, 57 

Set ACPI Power State, 243, 249, 250, 587, 592 

Set Auxiliary Log Status, 419, 420, 430, 589, 597 

Set BMC Global Enables, 73, 84, 85, 91, 269, 270, 
587, 592 

Set BMC Global Enables command, 73, 84, 85, 91 

Set Bridge ProxyAddress, 590, 601 

Set Bridge State, 590, 601 

Set Channel Access, 51, 52, 56, 57, 171, 269, 296, 
301, 302, 307, 309, 341, 397, 587, 593 

Set Channel Access command, 51, 52, 57 
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Set Chassis Capabilities, 385, 588, 595 

Set Event Receiver, 35, 72, 73, 221, 401, 437, 463, 
465 

Set Event Receiver command, 72 

Set ICMB Address, 590, 601 

Set In Progress, 286, 316, 346, 347, 375, 376, 393, 
394, 409, 410 

Set Last Processed Event ID, 224, 407, 408, 414, 
588, 596 

Set PEF Configuration Parameters, 407, 408, 588, 
596 

Set Power Restore Policy, 385, 391, 588, 595 

Set PPP UDP Proxy Transmit Data, 345, 367, 590, 
600 

Set SDR Repository Time, 438, 446, 589, 597 

Set SEL Time, 419, 428, 445, 446, 589, 597 

Set Selector, 286, 316, 319, 320, 321, 346, 354, 375, 
393, 398, 409, 411, 412 

Set Sensor Event Enable, 437, 451, 458, 522, 529, 
555, 589, 596 

Set Sensor Hysteresis, 437, 451, 455, 456, 589, 596 

Set Sensor Threshold, 451, 589, 596 

Set Sensor Thresholds, 437, 456, 525, 531 

Set Sensor Type, 437, 451, 469, 589, 596 

Set Serial Modem/Mux, 173 

Set Serial/Modem Configuration, 345, 346, 590, 598 

Set Serial/Modem Mux, 170, 171, 172, 173, 174, 175, 
180, 345, 352, 366, 373, 590, 599 

Set Session Privilege command, 62 

Set Session Privilege Level, 269, 273, 274, 296, 297, 
587, 593 

Set System Boot Options, 198, 385, 392, 393 

Set User Access, 296 

Set User Access command, 53, 191, 192, 307, 359, 
361 

Set User Access Command, 269, 307, 308, 587, 594 

Set User Callback Options, 345, 350, 371, 590, 600 

Set User Name, 269, 311, 588, 594 

Set User Password, 269, 312, 313, 588, 594 

Set User Password Command, 269, 588, 594 

Set Watchdog Timer, 332, 379, 380, 381, 382, 383 

Set/Get Channel Access, 191 

Set/Get User Access, 191 

Set/Get User Name, 191 

SetChassisDeviceld, 590, 602 

SetDiscovered, 590, 602 

SetEventDestination, 590, 602 

SetEventReceptionState, 590, 602 

Settable Threshold Mask, 523, 525, 527, 531 

Shared Mode, 51, 173 

Side-band interface, 123 

Simultaneous open sessions, 62 

Simultaneous sessions, 55, 62, 308 

Single-session connection, 56, 57 

SLAAC Timing, 143, 329, 330 
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Slave Address, 40, 46, 47, 137, 182, 226, 252, 281, 
401, 402, 403, 422, 431, 440, 491, 521, 527, 528, 
533, 540, 541, 542, 543, 544, 545, 562, 576 

Slave Address Field, 563 

Slot/Connector sensor, 9 

SMB Alert signal, 14 

SMBus 2.0 Block-Read protocol, 68, 69 

SMBus 2.0 Block-Write, 68, 69, 576, 577 

SMBus 2.0 Output, 68 

SMBus slave, 14, 281 

SMI event flags, 95 

SMI Handler, 7, 24, 25, 47, 54, 79, 93, 95, 97, 99, 
104, 218, 424 

SMIC interface, 18, 93, 94, 96, 102, 103, 403 

SMIC interface registers, 93 

SMIC interface, defined, 93 

SMIC registers, 93 

SMIC System Interface Format, 49 

SMIC/BMC Interface Registers, 94 

SMM Messaging, 54, 269 

SMS LUN, 72, 73 

SMS Message channel, 272 

SMS transaction, interrupted, 93 

SMS, defined, 48 

SMS ATN, 64, 81, 82, 83, 85, 86, 91, 92, 94, 95, 108 

SMS_ATN bit, 64, 81, 82, 83, 85, 94 

SMS_ATN flag, 82, 86 

SMS_WR_START, 96 

SNMP Traps, 20, 33, 417 

Snoop ACCM Control, 358 

Snoop Control, 357 

Snoop Receive ACCM, 360 

Software ID, 46, 47, 62, 80, 102, 103, 106, 137, 182, 
194, 226, 403, 404, 422, 431, 440 

Source Address, 132, 135 

Source IP Address, 132, 135, 188, 361, 368 

Source Port, 128, 129, 132, 135, 188 

Source Port Number, 368 

Standardized system interfaces, 17 

Static IP addresses, 140 

Status Register, 81 

Stream ID, 95, 98 

Stream switch, 98 

Suspend BMC ARPs, 139, 315, 332, 589, 598 

SW_Authentication_Type, 299 

SWIDs, 46, 275 

SYS GET BOOTOPT, 198 

SYS HEALTH QUERY, 199 

SYS POWER OFF, 199 

SYS POWER ON, 199 

SYS PWD, 198, 201 

SYS RESET, 199, 201 

SYS SET BOOTOPT, 198 

SYS SET TCFG, 199 

SYS TMODE, 198, 201 

System ACPI Power State, 513 
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System boot events, log, 23 Terminal mode options, 357 
System Boot Initiated, 512 Terminal Mode remote console, 194 
System Event Log, 14, 24, 28, 32, 40, 46, 54, 217, Terminal Mode Request, 196 

218, 402, 405, 419, 424, 427, 453, 486, 488 Terminal Mode Request Message, 194 
System Event Log Restrictions, 217 Terminal Mode Response, 196 
System Event Log, defined, 7 Terminal Mode Text Commands, 198 
System Event Log, minimum entries, 34 Terminal Mode, defined, 19 
System Firmware Hang, 508 Threshold Assertion Event Mask, 524 
System Firmware Progress, 26, 505, 508 Threshold Deassertion Event Mask, 525 
System FRED Intrusion, 234 Threshold Settings, 484 
System GUID, 151, 236, 284, 285, 411 Timeout value, 61 
System Interface, 34 Timer Actions, 379, 382, 383 
System Interface Register, 564 Timer Use Expiration flags, 381, 382, 383 
System Management Software, 2, 7, 24, 33, 46, 47, Timer Use field, 380 

71, 83, 85, 93, 104, 105, 217, 225, 273, 380, 436, Timer use fields, 33 

482, 498, 499, 536, 550, 555 Timestamp Format, 429, 430, 488 
System management software, defined, 48 Time-to-Live, 132 
System Management Software, purpose, 24 Tolerance, 61, 455, 482, 483, 526 
System Negotiation Snooping, 357 Tolerance value, 61 
System relative, 26 Total Length, 132, 188 
System reset action, 34 Transaction size requirements, 67 
System Software ID, 46 Transfer End, 97 

Transfer Middle, 97 
T Transfer Start, 97 


Transfer Stream Control Codes, 99 

Transfer Stream Status Codes, 99, 101 

Transition to Active, 499, 503 

ae en ns Transition to Busy, 499, 503 

ontirmation, . Transition to Idle, 499, 503 

TAP Control-character escaping mask, 356 Transmit ACCM. 360 

TAP Escaping, 205 i 

TAP Flow. 582 TX DATA RDY, 95, 96, 97, 98, 100 

TAP Page, 20, 168, 204, 232, 233, 234, 298, 353, 
354, 356 


TAP, 204 
TAP Account, 354, 356 


U 


TAP Page Success Code, 205 UDP Checksum, 128, 129, 132, 135, 187, 188 
TAP Pager ID Strings, 356 UDP datagrams, 123, 124, 131, 167, 168, 184, 191 
TAP Paging, 167, 204, 345, 351 UDP Header, 128, 129, 132, 135, 188 
TAP Paging transaction, 204 UDP Length, 128, 129, 132, 135, 187, 188 
TAP Passwords, 356 UDP Packets Received, 333 
TAP Response Codes, 205, 590, 600 UDP Proxy Packets dropped, 333 
TAP Service Setting Selector, 356 UDP Proxy Packets Received, 333 
TAP Service Settings, 354, 356 UDP/RMCP Packet, 189 
TAP SST Service Type, 356 Undetected error, 17 
Teaming, 138 Unspecified Error, 83 
Telocator Access Protocol, 204, 582 Upper Threshold Reading Mask, 525, 531 
Terminal Mode, 35, 47, 49, 57, 167, 168, 171, 176, User Access levels, 307 

177, 179, 193, 194, 197, 198, 199, 201, 275, 277, User Authentication, 59, 144 

351, 357, 369, 578, 579 User ID, 52, 53, 191, 192, 292, 298, 300, 308, 309, 
Terminal mode commands, 201 310, 311, 313, 371, 372 
Terminal Mode Configurations, 357 User Level Authentication, 56, 57, 59, 284, 294, 295, 
Terminal Mode input restrictions, 202 302 


Terminal Mode IPMI Message Bridging, 196 
Terminal Mode Line Editing, 201 

Terminal mode message, 196 

Terminal Mode message format, 194 
Terminal Mode messages, 194 


ser Level Authentication Disable option, 57 
ser Level Authentication Enable/Disable, 302 
ser Level commands, 56, 284, 302 

ser level privilege, 52 

ser Level privilege, 62, 295 
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User Link authentication enable/disable, 308 Watchdog Timer, 22, 23, 33, 34, 35, 51, 85, 91, 139, 
User password bypass, 397 201, 332, 379, 380, 381, 587, 592 
User privilege, 56, 192, 282, 586 Watchdog Timer actions, 379 
User privilege level, 52 Watchdog Timer Event Logging, 380 
User Privilege Limit, 22, 62, 297, 308 Watchdog Timer interface, 34 
User Session Limit, 308 Watchdog Timer, BIOS support, 381 
User support, minimum requirements, 53 Watchdog Timer, Timer Use, 379 
User-level authentication, 273, 274 wr data, 86 
WR END, 96, 98 
y WR_NEXT, 96, 98 


: e WR START, 98 
Valid RMCP Packets Received, 333 Write FRU Data, 448, 449, 589, 597 
Van Jacobsen compression, 191 . 
vi I IPMB. 75. 385 Write Transfer, 83, 84, 111 
mua ST WRITE_END, 83, 90 
WRITE_END control code, 83 


m Write_Next, 97 
Wake On Ring, 176, 352 WRITE_START, 83, 84, 90, 91, 96 
Wake-On-LAN, 139, 140 WRITE_START control code, 83 
Warm reset, 247, 512 WRITE_STATE, 82, 90, 91 
Warm Reset, 451 
Warm Reset Command, 247 X 
Watchdog commands, 26 X-bus, 18 
Watchdog expiration, 392 XC4003E, 107 


Watchdog sensor, 9, 509 
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